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

Sono stato il programmatore solitario nel mio lavoro per un bel po 'di tempo. Di solito ho letto articoli e post su

• Sistemi di controllo versione
• Integrazione / consegna continue
• Metodologie di sviluppo: Scrum, Waterfall, V-Model, Agile, XP, ecc.
• Gestione dei progetti software

Ma quasi tutti sembrano concentrarsi sui TEAM. Non sono una squadra, quindi quale sarebbe l'insieme minimo di pratiche per un solo programmatore? Considerare le seguenti condizioni:

• Non ho conflitti con il codice di altre persone.
• Non ho bisogno di mantenere alberi di file / directory, il mio ambiente di sviluppo si preoccupa del controllo delle versioni da solo (sviluppo basato su immagini).
• Non ci sono requisiti formali, i miei utenti non sanno cosa vogliono e sono d'accordo con quello.
• L'unico che potrebbe essere interessato a fornire una versione o una documentazione sono io, in pratica il cliente desidera RISULTATI e non si preoccupa delle metodologie software, ecc.

La mia opinione è che non voglio spendere (troppo) tempo ed energia in qualcosa che non sia direttamente correlato alle esigenze del cliente. Qualche consiglio?

Non c'è 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 contenti di te, non hai motivo di cambiare.

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

• Un sistema di controllo della versione : anche se si può pensare che un sistema di sviluppo basato su immagini faccia il lavoro per quanto riguarda i backup regolari e quant'altro, non si ha spazio per le funzioni sperimentali dove normalmente si dovrebbe usare un ramo . Inoltre, non è possibile conservare una versione importante del progetto ( tag ). Se mai ti espandessi oltre te stesso, gli sviluppatori che aderiranno penseranno che saranno all'inferno.
• Agile : questo metodo è estremamente applicabile per i clienti che non sanno cosa vogliono. Prima o poi, si renderanno conto di non voler spendere soldi per inseguire la coda: vorranno vedere progressi.
• Strumento di gestione del progetto - Questo è un must. È davvero formidabile riuscire a trattenere tutto nella tua testa, ma non è necessario. Essere disciplinati e utilizzare uno strumento di gestione del progetto (ad es. Redmine ) ti consentirà di separare i tuoi compiti e ti darà una cronologia del tuo lavoro di facile consultazione. Sarà molto importante quando inizi a caricare l'ora.

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

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

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

Un'altra cosa che non ho visto menzionato è uno script di build in un solo passaggio . Questa non è un'integrazione continua diretta (questa frase è incline a BS secondo me), ma uno strumento molto utile. Ogni volta che devi effettuare un aggiornamento di emergenza, puoi semplicemente eseguire lo script e completarlo. Quando ci si avvicina alla fine del progetto, capita anche che siano necessarie più build al giorno. La mia esperienza è che ripaga molto, anche se il processo di compilazione non è troppo complicato. È anche possibile aggiungere funzionalità di upload ftp, report via e-mail, esecuzione di unit test, creazione di programmi di installazione, firma ecc. Avere lo script scritto dall'inizio è facile da mantenere ed espandere con più passaggi man mano che il progetto avanza.

Risponderò solo a uno, il controllo della versione è estremamente importante per qualsiasi progetto e non solo per quelli di gruppo. Ci vuole un po 'di tempo extra quando lo si utilizza ma fornisce una ricca cronologia su cui ripiegare, non è un proiettile d'argento ma è sicuramente bello poter tornare a una copia funzionante se davvero funzionalità sperimentale ha rotto la maggior parte dell'applicazione.

Il controllo della versione è assolutamente necessario. Non solo per mantenere ok la fonte, ma per l'archeologia della fonte. Un anno dalla possibilità di verificare come una classe o una procedura evoluta potrebbe risparmiare molto dolore se si tenta di "correggere" un pezzo di codice strano.

Per le metodologie - consiglio vivamente il manifesto dei programmatori . Di solito offre grandi risultati in piccoli team a causa del sovraccarico zero e del fatto di non dover tenere a mente come funziona il gruppo di framework di contenitori di applicazioni per servizi Web CMS basati su ruoli MVC compatibili con JSR e portlet J2EE .