IMO, la migliore ricetta è prendere l'abitudine di lasciare sempre i tuoi progetti in uno stato che ti permetta di lasciarli cadere in un attimo e riprenderli sei mesi dopo, con un minimo di ritardo. Questo significa:
- Lavorare in iterazioni brevissime - non mesi, non settimane, nemmeno giorni lavorativi, ma ore o anche meno. Cerca una build utile, priva di bug e utile dopo ogni iterazione (anche se ciò potrebbe significare che il codice che hai scritto nella sessione corrente è inaccessibile a qualsiasi cosa che non sia il tuo unit test in questo momento: l'importante è che compili, passi i test, e non rompe nulla).
- Documenta tutto ciò che fai mentre lo fai.
- Non lasciare modifiche ininterrotte in giro: commit in anticipo, commit spesso.
- Se devi lavorare su diverse funzionalità in parallelo, usa i rami delle funzionalità.
- Lascia sempre il tuo codice in uno stato leggibile. Refactor in anticipo, refactor spesso.
- Scrivi test automatici adesso . I test automatici sono parte integrante del ciclo di sviluppo, non una funzione separata.
- Sii coerente. Più coerente sei, meno devi ricordare - se, ad esempio, tutti i metodi getter del tuo progetto seguono la convenzione di denominazione
getFieldName
, e sai che puoi essere sicuro al 100% che non ci sono eccezioni, tu < em> never deve cercare il nome di un getter.
- Sii religioso riguardo alla leggibilità.
- Progetta le tue API e librerie interne secondo il principio della sorpresa minima. Meno eccezioni significa meno tempo necessario per consultare la documentazione.
- Usa un bug tracker, un wiki, un sistema di ticket o anche un semplice file di testo vecchio, qualsiasi cosa ti aiuti a organizzare e dare la priorità ai tuoi pensieri. Non ha bisogno di molte campane e fischietti, a patto che tu possa facilmente lanciare pezzi casuali di informazioni e recuperarli rapidamente ed efficientemente.
L'idea centrale è "fire-and-forget": fai in modo che ogni progetto richieda risorse cerebrali minime per ogni compito dato e che quante più informazioni possibili possano essere esternalizzate ai tuoi strumenti: una wiki, il controllo del codice sorgente, e ovviamente il codice sorgente stesso. In questo modo, la quantità di pensieri nel tuo cervello che devi scambiare quando passi da un progetto all'altro è minima; idealmente, tutto ciò che devi fare è puntare il tuo ambiente di sviluppo (se questo è un IDE o una riga di comando non ha molta importanza) al progetto corrente, magari emettere uno o due comandi, e avrai tutti i suggerimenti di cui hai bisogno per tornare indietro.