Come dovrei pianificare il mio codice base?

Probabilmente ottieni tante visualizzazioni diverse quante saranno le risposte. Ma ecco la mia prospettiva.

Per cominciare, oltre 5000 linee di codice sono progetti molto piccoli. Ora, come procedi nel progettare progetti che crescono. In primo luogo, progetta il tuo sistema e non un codice. Il codice è in realtà secondario rispetto all'architettura. Inizia con il supporto dei requisiti minimi correnti. Metti un disegno semplicistico dei componenti coinvolti. Personalmente mi piace UML, ma qualsiasi cosa visiva sarà buona. Idealmente, si desidera aderire alle buone pratiche di progettazione qui (interfacce, separazione delle preoccupazioni ecc.)

Una volta supportati i requisiti minimi nella progettazione, codificalo. Di nuovo, cerca di aderire alle buone pratiche di codifica.

Dopodiché, aggiungerai iterativamente più funzionalità man mano che sorgono nuovi requisiti. Idealmente, vuoi aggiornare anche il tuo design.

Ciò che è importante, in base alla mia esperienza, non è progettare il sistema in previsione di requisiti non esistenti. Altrimenti il tuo progetto crescerà molto rapidamente e diventerà molto complesso in breve tempo. Ancora una volta: aderire alle buone pratiche e iniziare con requisiti attuali concreti.

Diagramma di flusso, diagramma di classe, schema dei casi d'uso sono i diagrammi indispensabili per i grandi progetti. Cerca e seleziona le librerie esterne che ti servono e cerca eventuali codici open source simili che puoi usare (per imparare e ridurre i tempi di sviluppo).

Ti suggerisco di acquistare una lavagna e amp; alcuni magneti colorati e amp; Pubblicalo. Ti aiuterà a identificare i tuoi compiti.

P.S. Tuttavia, più di 5000 righe di codici non sono "grandi". Un software CMS / Forum ha più di 5000 linee di codici.

Vorrei creare diagrammi di pacchetti e classi. Nel diagramma del pacchetto sarei interessato a raggruppare le classi e le interfacce in modo logico. Mi piacerebbe anche creare pacchetti interni ecc ...

Maprimadevipensareacosadovrebbefareilprogramma.Èpossibilecrearediagrammidiutilizzoomanualmente.Lofacciomanualmenteconildiagrammadelleclassiperchépreferiscoottenereilcodiceimmediatamenteedèpiùfacilescambiareinseguitoidiagrammidelleclassideipacchetti.Usareildiagrammadelleclassimidàilmiojava.Senonmipiace,locambiomanualmente.Ilnuovocodicevieneautomaticamenteaggiornatoneimieidiagrammi.Hounarappresentazionevisualeaggiornataadaltolivellodelmiocodice.Davveroutileperché,ancheseeseguoilcodice,possosemprededicarealcuniminutiaosservareilmodoincuiilmioprogettostaandandoinmodografico.Trascinomanualmenteleentitànelpacchettogiustomanualmenteperorganizzarlo.Pensocheilmiocodicestiausandomeglioilpiùaltolivellodipacchettidiastrazioneediagrammidiclasse.

alcuni dei miei colleghi hanno detto che il mio modo di lavorare è una merda .... ma mi piace: -)

Sicuramente. Ho una piccola lavagna "a secco" da usare per questo tipo di cose, ma usa quello che ti piace. La cosa importante è che puoi facilmente abbassare i tuoi pensieri e vedere il quadro generale di come tutto si combina perfettamente.

Alcune persone preferiscono piani più formali, come i diagrammi UML, ma ritengo che sia troppo facile farsi prendere dal microgestione su come dovrebbe apparire ciascun metodo. Ancora una volta, però, usa quello che ti piace.

EDIT: potresti anche essere interessato a programmazione alfabetica . L'idea è che puoi pianificare tutto e gradualmente diventare più specifico. Ad esempio, potresti dire che il tuo programma è composto da:

1. Ottenere il testo dall'utente
2. Conversione del testo in un'immagine
3. Salvataggio dell'immagine risultante sul disco

Quindi potresti affinare la tua idea di convertire il testo in un'immagine. In questo modo potrebbe essere:

1. Determina il numero di righe che il testo dovrebbe occupare
2. Seleziona colori casuali per il testo e lo sfondo
3. Elabora in un formato adatto

Quindi potresti perfezionare l'idea di scegliere colori casuali e presto ti limiterai a scrivere codice normale.

Per me, l'attività di sviluppo del software è una serie di disegni progressivamente più fini per risolvere un particolare problema. Quando hai un'idea di alto livello di ciò che stai creando, il tuo progetto potrebbe essere qualcosa di molto alto, come "ci sarà un'applicazione web che parla con un database SQL e più servizi web" o qualcosa del genere. Poi, mentre approfondisci i dettagli di ogni pezzo, ottieni una grana più fine nel design. A seconda della complessità della soluzione ci saranno più o meno iterazioni dello sforzo progettuale. L'iterazione finale prevede la creazione del codice effettivo che implementa i livelli superiori del design.

Per me, la differenza tra architettura e design è minima, e sono solo diverse iterazioni del processo che descrivo sopra. La linea tra i due è sfocata e diversa per persone diverse.

Esiste un'arte per decidere a quale livello di dettaglio del progetto andare, per quali parti dell'applicazione e in quali punti del ciclo di vita del progetto. Per progetti ad alto rischio e alta complessità potresti voler avere un progetto molto dettagliato prima di scrivere una riga di codice. Per i progetti più piccoli, puoi fare a meno di fare un po 'di design frontale e sbattere un po' di codice e vedere cosa non funziona e riprogettare quelle aree. Non c'è solo una risposta in scrittura qui. Di solito è da qualche parte tra questi due estremi.

Ho un post sul blog che parla di dei principi che uso quando mi avvicino all'architettura. Potrebbe esserti d'aiuto quando pensi in questo modo. Alcuni articoli sono specifici di .NET ma la maggior parte non lo è.

Ero solito pormi la stessa domanda. Ora pratico solo lo sviluppo basato sui test e non mi preoccupo. Non pianifico affatto il codice, se non per seguire gli standard per l'architettura scelta. Quando avvio un progetto, ho un'idea di ciò che sarà necessario, ma man mano che procede lo sviluppo cerco di mantenere una mente aperta. Seguendo lo sviluppo basato sui test e rifacendo continuamente il codice, non devo "pianificare" il codice. Ho appena soddisfatto un caso di test dopo l'altro, e il design emerge dal refactoring. Questo è sempre un design migliore di tutti i piani che avrei potuto fare prima della codifica.