Qual è il sottoinsieme minimo di pratiche migliori / ben note nello sviluppo di software per un programmatore solista? [chiuso]

Non esiste una risposta giusta a questa domanda perché dipende da ogni persona. Se usi un iPad per fare tutto il tuo lavoro di sviluppo e i tuoi clienti sono felici con te, non hai alcun motivo per cambiare.

Se, tuttavia, fossi nella tua posizione, farei rispettare con forza quanto segue:

• Un sistema di controllo della versione - Sebbene si possa pensare che un sistema di sviluppo basato su immagini svolga il lavoro sui backup regolari e quant'altro, si ha a che fare con zero spazi per funzionalità sperimentali in cui normalmente si usa branch . Non hai nemmeno modo di conservare una versione importante del progetto ( tagging ). Se ti espanderai al di là di te stesso, gli sviluppatori che parteciperanno penseranno che sono all'inferno.
• Agile : questo metodo è estremamente applicabile per i clienti che non sanno cosa vogliono. Prima o poi capiranno che non vogliono spendere soldi per inseguire la loro coda - vorranno vedere progresso.
• Strumento di gestione del progetto : è obbligatorio. È molto formidabile essere in grado di trattenere tutto nella tua testa, ma non devi. Essere disciplinati e utilizzare uno strumento di gestione del progetto (ad es. Redmine ) ti consentirà di separare le tue attività e offrirti una cronologia di facile consultazione del tuo lavoro. Sarà molto importante quando inizierai a caricare l'ora.

Il controllo della versione è un must assoluto per ogni programmatore, anche solo per un programmatore. Significa che puoi recuperare in modo semplice e veloce da file cancellati e modifiche complesse che sono semplicemente sbagliate.

Fondamentalmente ti salva dalla stupida merda che fai quando vai a lavoro sospeso.

Come altri dicono, il controllo della versione o la gestione del codice sorgente è estremamente importante. Usa un DVCS e impara tutto a riguardo. Non importa quale sia, anche se potrebbe esserti utile se ne scegliessi uno popolare: git o mercurial.

Un'altra cosa che non ho visto è uno script one-step build . Questa non è un'integrazione continua diretta (questa frase è a mio avviso soggetta a BS), ma uno strumento molto utile. Ogni volta che hai bisogno di fare un aggiornamento di emergenza, puoi semplicemente eseguire lo script e averne a che fare. Quando ci si avvicina alla fine del progetto, accade anche che siano necessarie diverse build al giorno. La mia esperienza è che paga molto, anche se il processo di costruzione non è troppo complicato. È anche possibile aggiungere funzionalità di upload ftp, generare report via e-mail, eseguire test di unità, creare programmi di installazione, firmare, ecc. Avere lo script scritto dall'inizio è facile da mantenere ed espandere con più passaggi man mano che il progetto avanza.

Risponderò a uno, il controllo della versione è di enorme importanza per qualsiasi progetto e non solo per quelli di gruppo. Ci vuole una piccola quantità di tempo extra quando lo stai usando, ma ti offre una ricca storia da cui puoi ricorrere, non è un proiettile d'argento ma è certamente bello poter tornare a una copia funzionante se davvero la funzione sperimentale ha interrotto la maggior parte dell'applicazione.

Il controllo della versione è assoluto. Non solo a causa del mantenimento della fonte ok, ma a causa dell'archeologia di origine. Un anno dall'essere in grado di verificare come una classe o una procedura evolute potrebbe risparmiare un sacco di dolore se si tenta di "sistemare" qualche pezzo di codice strano.

Per le metodologie - consiglio vivamente il manifesto dei programmatori . Di solito dà ottimi risultati in piccoli gruppi a causa di zero spese generali e non dover tenere a mente come il gruppo di framework di contenitori di applicazioni per servizi Web CMS basati su ruoli JCM compatibili con portlet J2R J2R supportati .