Quale processo di sviluppo software dovrei imparare prima per un progetto solista? [chiuso]

Ecco il processo che utilizzo per lo sviluppo in solitario:

• Configura un sistema di controllo della versione e un sistema di tracciamento dei bug. Ci sono un sacco di opzioni per entrambi. Io uso Mercurial & FogBugz personalmente.
• Metti tutto ciò che deve essere fatto nel bug tracker.
• Scegli un bug, risolvilo.
• esegui il commit del tuo sistema di controllo della versione.
• risolvi il problema.

In questo modo puoi avere una chiara idea di dove il tuo progetto sta andando e un chiaro senso di realizzazione mentre lo attraversi.

Quando lavori da solo, difficilmente troverai un "processo" per te che meriti quel nome. È meglio concentrarsi sul fare correttamente la parte di programmazione, usando correttamente il controllo della versione, scrivendo i test delle unità, tutto ciò che rende un buon codice.

Controllo versione

Se c'è una cosa di cui ogni progetto ha bisogno (inclusi i progetti esclusivi) il suo controllo di versione.

Qualunque altra cosa che usi è facoltativa (ma il controllo della versione è d'obbligo (auguro alle università molto di più sull'argomento)).

Sviluppo basato su test

È bello avere come puoi facilmente individuare le regressioni nell'interfaccia man mano che il codice viene aggiornato. È sicuramente molto bello lavorare su un progetto unico (ma non essenziale).

Un piano e un metodo di monitoraggio modificati per il piano

Devi definire cosa vuoi costruire, come lo vuoi costruire e gli errori che hai fatto.

Se il tuo progetto diventa abbastanza grande in cui altre persone iniziano ad aderire, se hai rintracciato decisioni / problemi / errori, i nuovi contributi non devono necessariamente commettere gli stessi errori o andare in rovina che hai provato.

A tal fine qualche forma di DB di tracciamento dei bug / elenco delle caratteristiche / Project WIki.

Inoltre, annotando un piano (comprese le funzionalità che ti piacciono (potenzialmente con una lista prioritaria), sai cosa devi concentrarti nella fase successiva.

Prima di digitare un carattere di codice devi avere un piano. Ti suggerisco di iniziare scrivendo un documento dei requisiti che descrive che , non come, vuoi consegnare. Questo documento dovrebbe essere abbastanza generico da poter essere implementato in qualsiasi linguaggio di programmazione adatto, ma abbastanza dettagliato da fornire un dominio e un intervallo per ogni sottoinsieme erogabile. Esaminare il documento alla ricerca di incongruenze, come requisiti incompleti o in conflitto. Continua a esaminare fino a quando non sei soddisfatto della completezza del documento.

Una volta completata la specifica dei requisiti, è necessario un piano per come implementerai il software. Questo è noto come un documento di progettazione software. Dovrebbe delineare l'architettura generale del progetto e fornire dettagli per ogni classe, modulo, funzione, ecc. Una persona che legge il documento di progettazione del software dovrebbe essere in grado di vedere come ogni parte del progetto interagisce con le altre parti. Rivedi e rivedi questo documento fino a quando non sei soddisfatto della sua completezza.

Una volta che questi due documenti sono stati fatti, puoi iniziare l'attuale processo di codifica. Questi documenti servono anche a istruire nuovi aiutanti sul progetto. Una specifica dei requisiti ben scritta ti consentirà di assegnare un sottoinsieme dei requisiti a un'altra persona e un documento di progettazione software ben scritto assicurerà che tali elementi siano codificati e testati correttamente e all'interno dei domini e degli intervalli specificati.

Hai provato la Tecnica Pomodoro ? Il problema più grande con il lavoro lungo è che non hai colleghi per mantenerti concentrato. Usare il pomodoro potrebbe aiutarti almeno con quello.

Però non farà alcun smalltalk ...

Hai un cliente? O è solo un progetto di miglioramento personale (per imparare come fare un'adeguata ingegneria del software)? I problemi chiave della maggior parte dei progetti sono legati alla gestione di una squadra. Ti raccomando:

• Utilizza un repository di codice e esercitati a effettuare il check-in e il check-out con commenti coerenti.
• Utilizzare un sistema di tracciamento dei bug e tenere traccia dei bug (in sospeso, in corso, corretti, differiti).
• Trova un sistema di documentazione di commenti / fonti che puoi tollerare e utilizzare. Io personalmente preferisci Doxygen, ma YMMV.
• Crea una build con un solo pulsante e crea build regolari.
• Scrivi test e usali.
• Crea una sorta di diagramma di flusso per mostrare il flusso di 10.000 piedi attraverso l'applicazione.
• Crea un diagramma di oggetti che mostra come i tuoi moduli sono interconnessi.

Consiglierei gli approcci:

1. Documenta il tuo codice in modo che quando torni ad esso, sembra qualcosa di familiare
2. hanno prove scritte per diverse funzionalità.
3. Segui Agile in modo che tu possa vedere il risultato dei tuoi sforzi in breve tempo e così facendo ti daranno la motivazione per andare avanti.
4. Come sempre, continua ad imparare.