Mantenere un elenco chiaro dei tuoi obiettivi è vitale. È facile per il feature creep assumere un progetto autogestito. Anche l'approccio TDD "è fatto quando funziona" è utile. Questo ti impedisce di diventare un perfezionista.

Una cosa che mi aiuta veramente è immaginare cosa un altro ingegnere o un project manager direbbe in una determinata situazione. Spesso riesco a "vergognarmi" di codice errato, oppure a tornare in pista se il programma sta scivolando.

Qui vai ... link

XP si adatta bene perché è ottimale per i piccoli gruppi focalizzati ...

• Puoi creare un foglio di lavoro per le richieste di funzionalità, assegnandogli una priorità e & scegli quello più in alto.
• definisce i criteri di accettazione (come appare) e lo codifica in un test eseguibile
• Successivamente, definisci le attività di progettazione da eseguire
• Scrivi i test unitari, fai la cosa più semplice (YAGNI) e rifatta tutto il tempo. L'obiettivo è rendere il test di accettazione esterno
• Timebox ogni sessione. Per un'efficace gestione del tempo, puoi anche consultare la tecnica Pomodoro .
• Usa controllo versione & Imposta un server CI / un file batch per creare un'installazione o un zip del tuo software
• Demo frequentemente. Instrada il feedback nel foglio di lavoro originale e riprioritizza

L'unica cosa che non potresti fare in un team di uno è PairProgramming.

Se lavori da solo. Ecco i consigli:

1. Fai il minimo lavoro a basso livello possibile. Usa tutta la libreria e gli strumenti che puoi eventualmente includere cose che ritieni di poter facilmente codificare (non farlo, basta usare la libreria).
2. Adotta l'approccio top-down. Codifica solo le cose di cui hai veramente bisogno.
3. Quando vedi un problema in termini astratti, cerca su Google e usa i documenti di ricerca della comunità accademica che sono già stati provati. Hai solo bisogno di codificare il loro algoritmo.
4. Progetta il tuo sistema in modo che tu possa liberamente cambiare le cose il più possibile. (incluso copia e incolla del codice da qui a lì). Lo scopo è quello di farti risparmiare tempo quando ti rendi conto di aver commesso un errore. Cerca di ridurre al minimo la quantità di lavoro che devi buttare via quando commetti un errore. Un pezzo di codice che deve essere gettato via (invece di copiare e incollare da qui e là) è l'equivalenza del tempo che hai perso scrivendo quel codice.
5. Hai molti test automatici in modo da poter eseguire regolarmente test di regressione ogni volta che apporti una modifica
6. Separa le responsabilità del tuo design (cioè abbatti l'accoppiamento). Rendi le cose il più modulari possibile
7. Utilizzare un debugger per eseguire il debug e utilizzare la ricerca binaria per trovare il difetto.
8. Riforma costantemente il tuo codice per ridurre l'accoppiamento (esplicito) e l'esposizione dei metodi pubblici (accoppiamento implicito).
9. Niente di veramente. Questo è qui solo nel caso in cui riesca a inventare qualcosa di nuovo: P

Recensioni del codice.

Questi sono particolarmente utili in quanto spiegherai il codice a qualcuno che non ha lavorato allo stesso progetto, in modo che non abbiano nessuna delle tue ipotesi su come dovrebbe funzionare.

Avranno anche il vantaggio di condividere le conoscenze intorno all'azienda in modo tale che quando qualcun altro debba lavorare al progetto (a causa di persone occupate altrove, malate, dimettersi o licenziati) non dovranno ricominciare da capo.

Nella mia azienda il nostro gruppo lavora tutti allo stesso progetto, ma su sezioni relativamente indipendenti. Una cosa che facciamo molto qui è quando qualcosa che stai facendo sembra un po 'complicato, o sei su una biforcazione con più di un modo per implementare qualcosa, prendi qualcun altro e discuti i pro e i contro prima procedete. Se aspetti di ritenere che il tuo codice abbia finito di fare una revisione, di solito hai già investito troppo tempo per prendere in considerazione importanti cambiamenti architettonici, anche se sicuramente molti dei difetti sono scoperti nelle revisioni del codice.

Inoltre, mi rendo conto che Test Driven Development è un po 'di buzzword saturata ultimamente, ma può essere di grande aiuto per gli sviluppatori solisti perché fornisce un controllo di qualità mentre si procede, e quando i test diventano difficili da scrivere sai che probabilmente hai bisogno di alcuni ristrutturazione del tuo codice. Aiuta anche i manutentori successivi a non rompere accidentalmente il codice in modo difficile da individuare.

Ho lanciato la mia versione di agile che si basa su storie, interazioni con i clienti, rilasci frequenti e sviluppo basato sui test. Uso una wiki per tracciare storie, coinvolgere il più possibile il cliente nella scrittura e far lavorare il cliente con me per definire le priorità e organizzarle in versioni. Io uso TDD per guidare la progettazione e l'implementazione. Ho creato un server QA in cui il cliente può provare le versioni frequenti (a volte ogni giorno con lo sviluppo di nuove funzionalità) in modo da ottenere rapidamente un feedback. Raramente vado più di 3 iterazioni senza un rilascio al QA. Il cliente deve decidere quando la versione del QA dispone di funzionalità sufficienti per la pubblicazione e se non è necessario sviluppare altre funzioni dall'elenco.

Ti suggerisco quanto segue:

1. Sviluppo basato su test
2. Eavy uso di "TODO: note qui" nel tuo codice quando vedi qualcosa che non sei in grado di fare immediatamente, e torna da loro quando hai tempo invece di rimanere su facebook aspettando che il tuo client richiamino
3. Scrivi il tuo codice come il tuo cliente lo comprerà guardando il codice non solo al risultato, immagina il tuo cliente come presidente per una revisione del codice.
4. Compila il tuo codice di asserzioni

Vorrei poter dire che ero in grado di praticare ciò che predico il 100% delle volte, ma BDD sembra essere un buon approccio per tenere conto della tua situazione:

Ecco un link con maggiori informazioni: link

Sono in una barca molto simile. Cerco di seguire i principi agili (così come li capisco) il più possibile. Probabilmente non sto facendo le cose "correttamente", ma ho avuto un grande successo sui miei progetti cercando di seguire principi agili. Ci vuole un'enorme quantità di disciplina, dal momento che non c'è una squadra per essere sicuro di non iniziare a prendere scorciatoie.

Trovo che l'uso di strumenti di formattazione del codice come ReSharper garantisca che, almeno visivamente, il codice sia facile da raccogliere per altri sviluppatori.

In termini di metodologie effettive, è difficile per uno sviluppatore singolo attenersi a qualsiasi particolare. Sono un consulente che generalmente lavora da solo, e trovo il modo più semplice sia per me sia per il cliente di utilizzare un processo agile. In genere cerco di convincere i miei clienti a inserire direttamente le loro esigenze in uno strumento come Trac (o lo farò, per loro conto). Questo non solo aiuta gli altri sviluppatori a identificare lo scopo del codice, ma anche te stesso a 3 mesi di distanza!

filosofia: XP / TDD + GTD

schema generale:

• intervista le parti interessate
• mockup di schermate, procedure dettagliate, prototipi di carta (se necessario)
• feature / story brainstorming (con e senza stakeholder)
• brainstorming del caso di test (con e senza stakeholder)
• progettazione generale / architettura in fase di riflessione (se necessario)
• pianificazione dell'iterazione (con le parti interessate)
• iterazioni
• revisione del processo, formazione, pianificazione della manutenzione, ecc. (se necessario)

Qualsiasi metodologia appropriata aiuterà - indipendentemente dal numero di persone coinvolte nel progetto. Quindi sceglierne uno alla volta e scopri come puoi applicare e mappare il tuo dominio e misurare i loro successi.

Forse è più interessante chiedere quali metodologie non eliminare perché c'è solo una persona che lavora al progetto.

E il tasto principale che spicca per me è il controllo del codice sorgente (Sì è uno strumento, ma fa parte del flusso di lavoro, quindi anche di un processo). Le persone potrebbero essere tentate di dare questo passaggio poiché "non hanno bisogno di supportare più persone che modificano il codice allo stesso tempo".

Ironia della sorte trovo che una soluzione di controllo delle versioni distribuita come GIT sia migliore per un individuo che qualcosa come SVN.

Se si tratta di buttare via il codice potrebbe essere un po 'loosey-goosey con metodologie, ma qualsiasi cosa importante e direi che il tuo modo di trattarlo come progetto di squadra con una persona è molto bello e disciplinato.

Scrivi il tuo codice per il prossimo ragazzo da leggere, non tu ... sii gentile con lui / lei. Anche il codice "buttare via" rimane in giro per sempre.

Agile

caratteristiche, storie e casi di test sono molto più istruttivi di una documentazione più formale, e una serie di test di lavoro è migliore per dimostrare come usare qualcosa o come funziona qualcosa di qualsiasi quantità di alberi morti

È anche più facile consegnare il lavoro tra le iterazioni.

Come consulente personalmente, ti suggerirei di trovare un modo per avere sempre almeno due sviluppatori in qualsiasi incarico.

Sono d'accordo con l'andare agile e lasciando una traccia agile di storie e test che altri possono seguire, ma non credo che nessun altro processo o metodologia possa attaccare mentre le persone lavorano in solo.

Penso che le recensioni sul codice siano un buon inizio ma mi piace quando è reso informale e divertente, come fare una recensione del codice Pair o una coppia di programmi per affrontare un certo problema / problema o qualche miglioramento (ad esempio cambiare il codice legacy per incontrarlo nuovi standard di codifica). A volte due set di occhi sono meglio di uno ed è anche divertente, sento che condividere e discutere sembra più aperto. Potresti anche avere un pranzo formale / informale e discutere delle sessioni per parlare di ciò che hai fatto individualmente o come gruppo, ad es. menzione di un nuovo modello che hai usato o di nuove tecnologie come è stato risolto un problema?