Come devo pianificare la mia base di codice? [chiuso]

Attualmente sto lavorando a un progetto che sta per raggiungere oltre 5.000 righe di codice, ma non ho mai pensato completamente al design. Quali metodi devo usare per strutturare e organizzare il mio codice? Carta e penna? Diagrammi UML? Qualcos'altro?

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

Per cominciare, oltre 5000 righe di codice sono un progetto molto piccolo. Ora, come si fa a progettare progetti che crescono. Innanzitutto, si progetta il proprio sistema e non un codice. Il codice è in realtà secondario all'architettura. Inizia con il supporto dei requisiti minimi di corrente. Inserisci un disegno semplicistico dei componenti coinvolti. Personalmente mi piace UML, ma qualsiasi cosa visiva andrà bene. Idealmente, vuoi aderire alle buone pratiche di progettazione qui (interfacce, separazione delle preoccupazioni, ecc.).

Dopo aver supportato requisiti minimi nella progettazione, codificalo. Ancora una volta, prova ad aderire alle buone pratiche di codifica.

Successivamente, aggiungi ripetutamente più funzionalità quando 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, diagramma di caso d'uso sono i diagrammi indispensabili per grandi progetti. Cerca e seleziona le librerie esterne di cui hai bisogno e cerca eventuali codici open source simili che puoi utilizzare (per imparare e ridurre i tempi di sviluppo).

Ti suggerisco di acquistare una lavagna e alcuni magneti colorati e Post-It. Ti aiuterà a identificare i tuoi compiti.

ps 5000+ righe di codice non sono "grandi", però. Un software CMS / Forum ha più di 5000 righe di codice.

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

Ma prima devi pensare a cosa dovrebbe fare il programma. È possibile creare diagrammi di caso utente o farlo manualmente. Lo faccio manualmente con il diagramma di classe perché preferisco ottenere immediatamente il codice ed è più facile passare ai diagrammi di classe del pacchetto in un secondo momento. L'uso del diagramma di classe mi dà il mio java. Se non mi piace, lo cambio manualmente. Il nuovo codice viene automaticamente aggiornato nei miei diagrammi. Ho una rappresentazione visiva di alto livello del mio codice. Davvero utile perché anche se scrivo codice posso sempre dedicare qualche minuto a vedere come il mio progetto procede in modo grafico. Trascino semplicemente le entità nel pacchetto giusto manualmente per organizzarlo. Penso che il mio codice sia migliore usando un livello più alto di pacchetti di astrazione e diagrammi di classe.

_{(fonte: ejb3.org )}

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

Decisamente. Ho un piccolo "tablet" lavagna a secco da usare per questo genere di cose, ma usa qualunque cosa tu sia a tuo agio. L'importante è che tu riesca ad abbassare facilmente i tuoi pensieri e vedere il quadro generale di come tutto si adatta insieme.

Alcune persone preferiscono piani più formali, come i diagrammi UML, ma ritengo che sia troppo facile lasciarsi sorprendere dal micromanaging di come dovrebbe apparire ogni metodo. Ancora una volta, però, usa tutto ciò che ti piace.

EDIT: potresti anche essere interessato alla 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 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. Quindi potrebbe apparire come:

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

Quindi potresti affinare l'idea di scegliere colori casuali e presto stai solo scrivendo un codice normale.

Per me, l'attività di sviluppo del software è una serie di progetti progressivamente più precisi per risolvere un problema particolare. Quando hai solo un'idea di alto livello di ciò che stai costruendo, il tuo progetto potrebbe essere qualcosa di altissimo livello, come "ci sarà un'applicazione web che parla con un database SQL e più servizi web" o qualcosa del genere. Quindi, man mano che si approfondiscono i dettagli di ogni pezzo, si ottiene un aspetto più fine nel design. A seconda della complessità della soluzione, ci saranno più o meno iterazioni dello sforzo di progettazione. L'iterazione finale prevede la creazione del codice effettivo che implementa i livelli più alti del progetto.

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

C'è un'arte nel decidere a quale livello di dettaglio del design andare, per quali parti dell'applicazione e in quali punti del ciclo di vita del progetto. Per progetti ad alto rischio e ad alta complessità, potresti voler avere una progettazione molto dettagliata prima di scrivere una riga di codice. Per progetti più piccoli, puoi cavartela facendo pochissimo il design frontale e sbattendo un po 'di codice e poi vedendo cosa non funziona e riprogettando quelle aree. Non c'è una sola risposta scritta qui. Di solito è da qualche parte tra quei due estremi.

Ho un post sul blog che parla di alcuni dei principi che uso quando mi avvicino all'architettura. Potrebbe esserti utile quando pensi in questo senso. Alcuni articoli sono specifici di .NET ma la maggior parte no.

Mi ponevo la stessa domanda. Ora pratico solo lo sviluppo guidato dai test e non me ne preoccupo. Non "piano" il codice affatto, tranne per seguire gli standard per l'architettura scelta. Quando inizio un progetto, ho un'idea di ciò che sarà necessario, ma man mano che lo sviluppo procede, cerco di mantenere una mente aperta. Seguendo lo sviluppo guidato dai test e continuamente il refactoring del 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 qualsiasi piano avrei potuto fare prima della codifica.