Come posso abbattere e pianificare un progetto di programmazione personale? [chiuso]

Non c'è niente di sbagliato in ciò che stai facendo se il tuo scopo è quello di imparare. Molti sviluppatori lasciano dietro di sé una serie di applicazioni scritte a metà quando hanno terminato tutto ciò che è interessante in esse.

Tuttavia, se vuoi scrivere qualcosa e terminarlo, scegli un problema che vuoi risolvere, quindi fai il minimo necessario per risolverlo. Utilizza le librerie e gli esempi di codice esistenti e collegalo insieme. Una volta che hai qualcosa funzionante, torna indietro e puliscilo ed espanderlo.

[Modifica]

Se stai cercando ispirazione, ci sono molti posti da cui iniziare. Microsoft ha il codice 4 divertente sito. Ci sono migliaia di applicazioni open source che richiedono correzioni, miglioramenti, test automatizzati e documentazione su siti come github.com e codeplex.com. Leggere il codice di altre persone ti aiuta anche a imparare nuove tecniche e librerie.

Congratulazioni per il tuo ruolo di espansione. L'elicitazione dei requisiti e la gestione dei requisiti sono due grandi abilità per gli sviluppatori. A volte questi ruoli sono interamente controllati dai product manager al di fuori dell'organizzazione di sviluppo e il risultato può essere molto limitante.

Il software di architettura per la facilità di espansione e manutenzione ha un impatto profondo su tutto ciò che facciamo. In un documento chiamato "sui criteri da utilizzare per la decomposizione di sistemi in moduli" , DL Parnas ha implementato un progetto due volte, una volta con la scomposizione funzionale e una volta con la decomposizione orientata ai dati. Quindi ha aggiunto alcune nuove funzionalità e preso le metriche sull'impatto sul codice. Il principale risultato è stato che i due metodi avevano proprietà molto diverse per mutevolezza, sviluppo indipendente e comprensibilità.

Il lavoro successivo pubblicato da Parnas come caso di studio del sistema avionico A-7E e l'uso di incapsulamento, occultamento delle informazioni e progettazione essenzialmente proto-object è stato molto influente su linguaggi di programmazione orientati agli oggetti e successivamente analisi e progettazione. È anche documentato nel libro "Software Architecture in Practice" di Bass, Clements, e Kazman.

Hai detto che il tuo codice si aggroviglia mentre espandi la portata dei tuoi progetti personali. Prendi in considerazione la possibilità di utilizzare quanto segue per mantenerlo in pista:

• Stai usando un oggetto orientato dove il codice è implementato come classi? Questo approccio è potente in termini di promozione della manutenibilità e riusabilità del codice.
• Quanto sono grandi le tue lezioni? Una grande classe che spesso è possibile mantenere molte cose. Se puoi fare in modo che ogni classe faccia una cosa bene (una tecnica chiamata separazione delle preoccupazioni), di solito è più facile da implementare e testare.
• Stai utilizzando il test dell'unità o lo sviluppo basato su test (TDD)? Se crei test per verificare che il tuo codice funzioni, allora con ogni iterazione o incremento, puoi verificare che funzioni ancora.
• Stai usando Git o qualche altro strumento di controllo del codice sorgente? L'uso di uno strumento per bloccare le modifiche alla fine di ogni ciclo di modifiche e test (di solito limitato a un giorno o meno) può dare a te (e agli altri membri del tuo team) una rete di sicurezza. Avere le revisioni del codice salvate può farti annullare le modifiche, ma, soprattutto, può aiutarti a enumerare ciò che hai cambiato tra quando ha funzionato e quando si è rotto. Di solito una di queste modifiche può essere nuovamente modificata per tornare a uno stato di lavoro.
• Stai utilizzando approcci iterativi / incrementali? Puoi leggere questi approcci su questa pagina di Alistair Cockburn che scrive ampiamente sullo sviluppo di Agile. Wikipedia ha anche una bella descrizione .

Spero che questo aiuti. Sono sicuro che la tua domanda susciterà una grande varietà di risposte utili qui su Stack Exchange.

Sono d'accordo con akton.

Se stai cercando di creare un prodotto funzionante. Definiscilo, disegnalo e poi codificalo.

Jeff Attwood ha scritto un blog su KISS e YAGNI .

Esamina Test Driven Development per evitare di demolire i progetti e riavviarli da zero. Se la tua app supera tutti i test, puoi rifattorizzare parti del codice che non ti piacciono. Rosso, Verde, Refactor.