Tre mesi fa stavo lavorando a un progetto, poi improvvisamente è apparso un altro progetto urgente e mi è stato chiesto di spostare la mia attenzione.

A partire da domani, tornerò al vecchio progetto. Mi rendo conto di non ricordare cosa stavo facendo esattamente. Non so da dove cominciare.

Come posso documentare un progetto in modo tale che ogni volta che guardo indietro non dovrebbe volerci più di qualche minuto per andare da qualsiasi parte lasciata. Ci sono le migliori pratiche?

Volevo solo contribuire con alcuni consigli che non saranno utili nella tua situazione attuale, ma puoi iniziare a implementarlo ora per aiutarti in futuro.

Naturalmente ci sono i candidati ovvi come liste di cose da fare e registri delle emissioni; guardare ai problemi aggiunti di recente dovrebbe darti un indizio su cosa stavi facendo quando sei stato rimosso dal progetto.

Sui progetti precedenti a cui ho lavorato, ci si aspettava che le persone avessero un registro dei progetti nell'ambito del processo di gestione della qualità. I contenuti non sono stati specificati in modo molto chiaro, ma l'idea era quella di tenere un registro giornaliero delle cose relative al progetto che potrebbero essere utili per il lavoro continuo in futuro o per le attività di revisione al completamento; per esempio:

• Osservazioni sulla qualità del progetto

  questo codice può utilizzare alcuni refactoring

  ha fatto un'implementazione rapida per farlo funzionare, ma ABC sarebbe meglio.

• Articoli / problemi di Todo che non si desidera registrare formalmente in un tracker di problemi

  "dovrebbe far funzionare questo metodo x < 0ma al momento non rientra nell'ambito di applicazione.

• Decisioni progettuali , soprattutto non banali.

  La nostra funzione di ordinamento standard esegue un ordinamento rapido, ma ciò non mantiene l'ordine degli articoli uguale nella condizione di ordinamento, di cui abbiamo bisogno qui.

  L'algoritmo ovvio sarebbe ABC, ma qui fallisce perché xpotrebbe essere negativo, quindi abbiamo bisogno della forma generalizzata ( link Wikipedia ).

• Problemi riscontrati e come li hai risolti. Un aspetto molto importante, a mio avviso personale: ogni volta che incontri un problema, annotalo nel registro.

  Controllato il codice ma ha dato l'errore XYZ0123, risulta che prima ho dovuto aggiornare il componente C alla versione 1.2 o successiva.

Gli ultimi due punti sono molto importanti. Ho spesso riscontrato una situazione o un problema simile - a volte in un progetto completamente diverso - e ho pensato "hmm, ricordo di aver passato una giornata su questo, ma qual è stata di nuovo la soluzione?"

Quando torni a un progetto dopo un po ', rileggere il registro del progetto (che sia il tuo o l'ultimo sviluppatore) dovrebbe riportarti nel flusso che avevi quando te ne sei andato e avvertirti di alcune trappole che tu potrebbe altrimenti cadere di nuovo.

Le liste di cose da fare sono magiche. Generalmente devi tenere un elenco di cose da fare attivo per ogni progetto e anche mentre sei impegnato nella programmazione, se pensi a qualcosa che deve essere fatto e non puoi farlo immediatamente, allora viene inserito nell'elenco. Conservare questo elenco in un luogo ben noto, in un foglio di calcolo o in un file di testo nella cartella del progetto in formato elettronico o nel diario di bordo.

Inoltre, ogni volta che lasci il progetto per la notte (o durante il fine settimana), prendi un post-it e scrivi la prossima cosa che avresti fatto sulla nota e incollalo sul monitor. Ciò rende più probabile il rientro rapido al mattino successivo.

Modifica :

Devo dire che le liste di cose da fare (in particolare le liste di cose da fare in ordine di priorità, separate per sede e progetto) sono una parte fondamentale del libro Getting Things Done , che ho trovato molto influente.

Cosa fare adesso?

Da domani tornerò al mio vecchio progetto e mi rendo conto di non ricordare cosa stavo facendo esattamente e da dove cominciare!

Suppongo che tu non abbia fatto nessuna delle prossime sezioni. Quindi cercare un elenco di cose da fare non funzionerà.

1. Blocca un periodo di tempo. Inseriscilo nel tuo calendario e passa il tempo a rivedere il progetto. Potrebbe essere la revisione di documentazione, codice, requisiti, ecc.
2. Accetta, ci vorrà un po 'per tornare alla velocità. Assicurati che tutti i soggetti coinvolti lo capiscano. Assicurarsi che si rende conto questo.
3. Inizia con un piccolo compito. Ricostruisci la tua fiducia facendo qualcosa di piccolo. Se si dispone di un elenco di nuovi elementi, esaminare prima quelli più piccoli. Questo non solo ricostruisce la tua fiducia, ma aiuta anche a riacquistare te stesso con il progetto.

Come renderlo migliore per te stesso in futuro?

Vorrei sapere come documentare il progetto in modo tale che ogni volta che guardo indietro non dovrei impiegarmi più di qualche minuto per andare da qualsiasi parte lasciata!

Innanzitutto, devi avere un sistema per tenere traccia dei tuoi todos. Hai un tale sistema ora? Come gestisci i tuoi progetti attuali?

Domani potrei essere investito da un autobus e la mia squadra avrebbe una buona idea di oltre il 90% dei miei oggetti d'azione. Questo perché ho un sistema coerente per documentare il mio:

• Todos immediati (<articoli di 1 settimana)
• "Bello avere" todos
• Pietre miliari e macro todos (dove i dettagli non sono significativi)
• Requisiti / note sulla riunione

Inoltre, utilizzo un VCS e commento il mio codice, ove appropriato.

Questo funziona per me e il mio team poiché sono lo sviluppatore principale. È possibile utilizzare una sorta di sistema di tracciamento dei problemi per un team. O un arretrato quando si lavora con Agile. Ci sono molte opzioni. Se sei veramente interessato a questo, leggi su Getting Things Done o altre metodologie di gestione delle attività pertinenti, che esistono quasi esattamente a causa di ciò che descrivi.

Qual e il punto?

Le specifiche del sistema sono meno rilevanti di quanto sia un sistema coesivo e lo si utilizza . E che lo usi. E usalo. Questo è importante. Più importante di un bel sistema perfetto che non usi. Non fare "bene la maggior parte del mio lavoro è qui, ma alcuni sono nella mia testa" o odierai te stesso di tornare su un progetto.

Inoltre, assicurati che i tuoi commenti spieghino "perché" piuttosto che semplicemente "cosa" per il codice. È molto più facile leggere "questo è correggere un bug con IE8" e ricordare cosa fa il codice di un commento che spiega semplicemente i dettagli tecnici.

A mio avviso, ci sono due parti per "riprendere" un progetto di codice:

1. Determinare da dove eri rimasto
2. Ricordando cosa ti resta da fare

Questa è una di quelle cose che, penso, se stai eseguendo il controllo della versione nel modo giusto, sarà il tuo "altro cervello".

Dove hai lasciato ? Fintanto che stai commettendo codice frequentemente, guarda il tuo ultimo changeset. Molto probabilmente ti farà correre qualcosa nella tua mente. Altrimenti, guarda i pochi precedenti, iniziando con i commit più vecchi e ripetitivi.

Per quanto riguarda ciò che resta da fare , un backlog dovrebbe servire a tale scopo (o a un elenco di cose da fare, o come si desidera nominarlo. Fondamentalmente voci per il futuro).

Non sono uno sviluppatore di software a tempo pieno. Sono un programmatore che hackerava nelle notti e nei fine settimana. Per questo motivo, quando il lavoro o altre cose non programmabili hanno una priorità maggiore, a volte posso passare giorni e settimane senza nemmeno tirare su il mio codice con un'occhiata. Quanto sopra ha dimostrato di essere abbastanza efficace.

Questa non vuole essere una risposta completa — ce ne sono già molte ottime che menzionano cose importanti come l'uso del VCS e del software di gestione dei progetti — ma piuttosto un addendum che aggiunge alcuni punti che non ho visto in nessun altro, che io trovo molto utile e che spero che anche altre persone possano trovare utile.

1. Nessuna attività è troppo presto o troppo piccola per essere annotata

Le persone di solito fanno elenchi TODO per le cose che hanno intenzione di fare in futuro , ma poiché la programmazione richiede concentrazione, e poiché possiamo essere interrotti in qualsiasi momento , ho trovato utile scrivere anche quello che sto facendo in questo momento, o quello che sto per iniziare in pochi secondi . Si può sentire che stai in zona e non si poteva forse dimenticare la soluzione che appena ti ha colpito in quel aha momento, ma quando il tuo collega di lavoro scende di vostro cubo visualizzare la foto del suo dito del piede infetto , e si è riuscendo a liberartene solo iniziando a rosicchiarti il ​​braccio , potresti desiderare di aver scritto una breve nota, anche se solo su una nota Post-It ™.

Ovviamente un altro mezzo più persistente potrebbe essere migliore (sono particolarmente affezionato a OmniFocus ), ma il punto è almeno averlo da qualche parte , anche se finirai in 20 minuti e poi butti via il Post-It ™. Anche se potresti scoprire che tali informazioni diventano utili, mettere su fogli presenze o fatture al cliente o quando il tuo capo / cliente ti chiede su cosa stai lavorando e che non ricordi. Se lasci cadere tutte queste note in una scatola, un cassetto o una cartella, quando si verifica una grande interruzione, un progetto che interrompe, puoi dare un'occhiata attraverso di esse e ricordare molte cose che hai fatto per ottenere il tuo codice al punto in cui trovalo quando ritorni al progetto.

2. Utilizzare una lavagna alla scrivania per catturare idee di grandi dimensioni

Ho una lavagna da 3 "x 4" vicino alla mia scrivania, quindi quando inizio un progetto posso fare il brainstorming delle soluzioni a tutti i problemi che percepisco in un progetto. Potrebbe essere diagrammi architettonici, casi d'uso, elenchi di rischi e ostacoli o qualsiasi cosa ti sembri rilevante.

Alcuni approcci più formalizzati richiedono di generare diagrammi e casi d'uso e così via come "risultati finali" in un formato cartaceo o elettronico, ma trovo che ciò possa creare molto lavoro extra e diventare una serie di sottoprogetti che terminano essere divorziato dallo scopo reale del progetto principale, e solo parte di un processo formalizzato che devi fare ma a cui nessuno presta molta attenzione. Una lavagna è la cosa più semplice che funziona davvero, almeno nella mia esperienza. È persistente quanto vuoi (con una macchina fotografica) e, soprattutto, ti permette di far decollare le tue idee immediatamente.

Penso meglio con una penna in mano, quindi scaricare i miei pensieri su una superficie bianca mi viene naturale, ma se non lo ritieni opportuno, ecco alcune domande che potrebbero aiutarti a decidere cosa è rilevante :

• Se fossi lo sviluppatore principale, in procinto di andare in luna di miele per 3 mesi mentre altri sviluppatori completavano il progetto, quale direzione generale avrei voluto dare loro? Quali idee dovrei assicurarmi di conoscere o quali approcci dovrei garantire? Di quali biblioteche o altre soluzioni utili vorrei essere sicuro di essere a conoscenza?
• Se questo progetto fosse la mia idea da un milione di dollari che sapevo avrebbe assicurato la mia futura indipendenza finanziaria, ma ero programmato per un intervento chirurgico critico che mi avrebbe reso inabile per 3 mesi, cosa avrei voluto che il mio futuro sé avesse, per garantire il completamento con successo di il progetto?

(Quando scarabocchio le idee per la prima volta, mi preoccupo solo che abbiano un senso per il mio sé presente. Una volta che sono giù posso guardarle in modo più critico e apportare modifiche per assicurarmi che abbiano un senso per il mio sé futuro o per gli altri. Preoccuparsi troppo di comunicare con gli altri mentre li scrivi inizialmente può portare al blocco degli scrittori: una mente intasata da obiettivi in ​​competizione. Scendi prima, preoccupati per la chiarezza in seguito.)

Ti consiglio di spendere i soldi per acquistare una lavagna decente, almeno 3 "x 4", e appenderlo nello spazio in cui lavori normalmente. Ci sono molti vantaggi di una lavagna fisica rispetto a qualsiasi sistema virtuale.

• È grande. Occupando molto spazio fa sentire la sua presenza e i piani su di esso sembrano far parte del tuo spazio di lavoro, aiutandoti a indicarti sempre la giusta direzione.
• È persistentemente presente: non è necessario avviare una determinata app o un sito Web per accedervi e non si rischierà di dimenticarsi di come raggiungerlo o di dimenticare che è lì.
• È immediatamente accessibile quando hai un'idea su cui vuoi riflettere.

Si perdono molti dei vantaggi se si utilizza una lavagna in una sala riunioni e si scatta un'istantanea con il telefono. Se guadagni programmando, vale la pena il costo di una lavagna decente.

Se si dispone di un altro progetto interrompere quella che ha riempito la lavagna, potrebbe essere necessario ricorrere a l'istantanea sul vostro telefono, ma almeno avrete che in 3 mesi, quando il progetto "urgente" è finito e si deve ritorna all'altro. Se vuoi ricrearlo sulla tua lavagna, probabilmente ci vorranno solo 15 minuti e potresti scoprire che puoi migliorarlo molto nel processo, il che rende molto utile quel piccolo investimento di tempo.

3. Rendere le parti interessate consapevoli dei costi di interruzione di un progetto

Trovo utile la metafora di un aereo: iniziare e completare un progetto è come far volare un aereo. Se effettui il salvataggio a metà del volo, l'aereo non si limiterà a sedersi in aria in attesa che torni su di esso, e avrai bisogno di un modo per viaggiare dal progetto / volo corrente a quello successivo. Infatti se sei nel mezzo di un volo da Phoenix a Fargo e ti viene detto che devi interrompere quel volo per prendere un altro aereo da Denver a Detroit, dovrai atterrare il primo aereo a Denver (che fortunatamente non è lontano dalla tua traiettoria di volo, non sempre nel caso di interruzioni reali) e qualcuno deve capire cosa fare del carico e dei passeggeri. Non si limiteranno a sedersi e ad aspettare per sempre.

Il punto di ciò per i progetti è che il passaggio da un progetto a un altro comporta un notevole dispendio di tempo e lascia molti punti da perdere.

In un progetto ci sono ovviamente e inevitabilmente molte cose che succedono nella tua testa mentre lavori e non tutti i pensieri possono essere serializzati su un supporto scritto, e non tutti i frammenti di quei pensieri che sono serializzati rimarranno una volta deserializzati. Anche se possiamo parzialmente catturare i nostri pensieri per iscritto, è un formato molto smarrito.

Il problema (come lo vedo io) è che i project manager e altri uomini d'affari pensano ai progetti come una serie di passaggi che spesso possono essere riordinati a piacimento (a meno che non vi sia una dipendenza esplicita sul loro diagramma di Gantt) e possano essere facilmente distribuiti tra le persone o in ritardo fino a quando non è più conveniente per l'azienda.

Chiunque abbia svolto una certa quantità di programmazione sa che i progetti software non possono essere trattati come blocchi Lego da spostare in qualsiasi modo tu voglia. Trovo che la metafora del viaggio aereo dia almeno agli stakeholder qualcosa di concreto a cui possono pensare che chiaramente non può essere trattato come una serie di passaggi diversi da riordinare per capriccio. Almeno rende facile capire il tuo punto che c'è un costo per tali interruzioni. Naturalmente è ancora una loro decisione, ma tu vuoi renderli consapevoli di questo prima che interrompano un progetto per dartene un altro. Non essere combattivo, ma offri informazioni utili e la prospettiva utile dello sviluppatore, pronto a fare tutto ciò di cui ha bisogno da te, ma semplicemente offrendo informazioni di cui potrebbe non essere a conoscenza se non glielo dici.

In breve:

1. Scrivete tutto quello che sei circa di fare, anche se non credo che si potrebbe eventualmente necessario mai scritto verso il basso. Anche una matita corta batte un lungo ricordo.
2. Brainstorming sull'immagine grande su una lavagna fisica a cui hai accesso persistente.
3. È possibile evitare interruzioni del progetto se si rendono consapevoli che i responsabili delle decisioni hanno un costo per tali interruzioni e almeno si saranno stabilite le aspettative in modo che sappiano che il progetto impiegherà un po 'più di tempo a riprenderlo.

Puoi consultare la cronologia del progetto nel tuo software di controllo versione di tre mesi fa. Leggi i tuoi messaggi di commit e le differenze più recenti per avere un'idea di ciò su cui stavi lavorando.

L'uso di un sistema di controllo del codice sorgente con strategie di ramificazione e fusione appropriate, in combinazione con un sistema di tracciamento dei problemi (come Redmine o GitHub ), ti aiuta a dividere in compartimenti le modifiche che hai apportato, dare loro direzione e documentare il tuo 'contesto' mancante come una parte naturale del flusso di lavoro.

1. Prima di iniziare una modifica del codice, assicurati che ci sia un 'problema' registrato nel tuo sistema di tracciamento dei problemi. Questo copre il pezzo mancante "cosa stavo facendo" del tuo lavoro.
2. Crea un ramo nel tuo sistema di controllo del codice sorgente e assicurati che le modifiche apportate a quel ramo siano SOLO correlate al problema sopra menzionato. Questo ti aiuterà a isolare i cambiamenti e ti darà una cronologia del cambiamento, rispondendo alla domanda "dove ho lasciato?" quando torni a lavorarci più tardi.
3. Una volta terminata la modifica, ricollegala nel trunk e chiudi il problema.

Ci sono molte risposte lunghe. Questo è breve su ciò che mi aiuta di più:

• Codice pulito.
• Codice pulito.
• Codice pulito.
• Controllo versione (diff e commit commenti).
• Una nota di post-it o un Todo-List o una Kanban-Board (vedi ad esempio Trello ed Evernote)

Tuttavia, Diffs, Commit commenti, Post-It notes, Todo-Lists o Kanban-Board possono essere erroneamente interpretati nel tempo per mancanza di contesto. Quindi ecco l'unica cosa che è più importante:

CODICE PULITO.

Come posso documentare un progetto in modo tale che ogni volta che guardo indietro non dovrebbe volerci più di qualche minuto per andare da qualsiasi parte lasciata.

Innanzitutto, ciò implica che nel progetto ci sono descrizioni e strutture di codice di alto livello che puoi facilmente cogliere in pochi minuti, al contrario di un milione di righe di codice senza struttura apparente e senza commenti.

Ci sono le migliori pratiche?

Le seguenti sono le migliori pratiche che ho adottato nel corso di una carriera di oltre 20 anni in progetti di dimensioni molto piccole o molto grandi e hanno servito bene me e i miei team. Fai domanda nell'ordine elencato man mano che il tuo progetto cresce:

1. Utilizza il controllo versione per ottenere una traccia gratuita di ciò che è accaduto, quando e chi ha applicato le modifiche. Ti consente inoltre di tornare facilmente a una versione precedente in qualsiasi momento.

2. Modularizza il tuo codice (a seconda del linguaggio e dell'ambiente di programmazione, usa classi, moduli, pacchetti, componenti).

3. Documenta il tuo codice. Ciò include la documentazione di riepilogo nella parte superiore di ogni file (cosa fa questo? Perché? Come si usa?) E commenti specifici a livello di funzioni, procedure, classi e metodi (cosa fa? Argomenti e valori di ritorno / tipi? effetti collaterali?).

4. Aggiungi TODOe FIXMEcommenta mentre stai programmando. Questo aiuta a ricordare i perché e le stranezze che entreranno inevitabilmente nella tua base di codice e che in seguito ti chiederanno WTF ?! . Per esempio:

   //TODO shall actually compute X and return it
   ... some code that does not compute X yet (maybe returns a fixed value instead)
   
   //FIXME make this constant time instead of n^2 as it is now 
   ... some code that works but is not efficient yet
   

5. Prendi l'abitudine di disegnare diagrammi per documentare la struttura e comportamenti complessi come sequenze di chiamate tra moduli / oggetti / sistemi ecc. Personalmente preferisco UMLet in quanto è veloce da usare, crea una bella grafica e, soprattutto, non ti ostacola . Ma ovviamente dovresti usare qualsiasi strumento di disegno che trovi funzioni. Ricorda che lo scopo di tali disegni è di comunicare in modo succinto, non di specificare un sistema nei minimi dettagli (!!).

6. Aggiungi test unitari all'inizio. I test unitari non sono solo ottimi per i test di regressione, ma sono anche una forma di documentazione sull'utilizzo dei moduli.

7. Aggiungi presto una documentazione esterna al codice . Inizia con un README che descrive le dipendenze richieste per eseguire e sviluppare il progetto, come installarlo, come eseguirlo.

8. Prendi l'abitudine di automatizzare le attività ripetitive . Ad esempio i cicli di compilazione / compilazione / test dovrebbero essere scritti in qualche modo (ad es. Nell'uso di JavaScript grunt, in Python fabric, in Java Maven). Questo ti aiuterà ad alzarti rapidamente quando torni.

9. Man mano che il progetto cresce, aggiungi più documentazione generando documenti in codice sorgente (usando una qualche forma di commenti in stile JavaDoc e uno strumento appropriato per generare HTML o PDF da esso).

10. Se il tuo progetto va oltre un singolo componente e prevede una distribuzione più complessa, assicurati di aggiungere la documentazione di progettazione e architettura . Notare ancora che lo scopo di questo è comunicare struttura e dipendenze piuttosto che piccoli dettagli.

Oltre ai suggerimenti sul tracciamento del progetto, elenchi di attività, Trello, ecc. Qualcosa che ho letto una volta che aiuta se stai praticando TDD è quello di allontanarti sempre dal tuo progetto con un nuovo test fallito da implementare ogni volta che ritorni al progetto (domani , la prossima settimana o il prossimo mese)

Siediti, fai "Esegui test" e riprendi da dove eri rimasto.

Oltre ai commenti / todo list / commit, è importante essere realistici.

A seconda delle dimensioni, della complessità e dello stato in cui hai lasciato il tuo lavoro, il riavvio di un progetto potrebbe richiedere del tempo. Per una base di codice sostanziale di molti componenti interagenti, potrebbero essere necessari giorni per arrivare alla massima velocità.

Una buona vecchia pazienza sarà utile.

Quando sono sopraffatto dopo essere tornato a un progetto dopo un po ', generalmente raccolgo l'unità di compito più semplice e più piccola e la implemento. Mi impedisce di perderti cercando di ricordare molte cose contemporaneamente e aumenta un po 'la fiducia. Più spesso, mi ritrovo a raccogliere automaticamente compiti sempre più grandi in poche ore.

Tengo un diario giornaliero del lavoro che faccio. Cosa ho fatto oggi, cosa è stato difficile oggi, qual è il passo successivo, quali idee avevo oggi per il futuro. Aggiungo anche un po 'di narrativa su come è stata la giornata: c'è stata una conversazione o un incontro interessante? Qualcosa ha fatto rabbia o delizia? Questo aiuta a mettere le cose in prospettiva quando in seguito leggo il mio diario.

Quando torno a un progetto dopo un po ', leggo le ultime voci nel diario per aggiornarmi sul progetto. Tutti quei piccoli dettagli quotidiani sono incredibilmente importanti per ricordare il processo di sviluppo. Fanno davvero molta differenza rispetto a una lista di cose da fare o alla normale documentazione di progetto, poiché ti ricordano com'è stato lavorare sul progetto e non solo come usare il prodotto.

Per me, trovo che il metodo più semplice per riprendere i progetti sia solo quello di tenere un registro costante delle note sul tuo lavoro. Trovo che "OneNote" di Microsoft sia particolarmente utile per conservare e raggruppare pagine di note. In particolare, la barra di ricerca rende estremamente facile trovare rapidamente le tue note su qualcosa.

Ecco alcune cose che faccio in OneNote che mi aiutano a riprendere i progressi sui progetti:

• Registri giornalieri / settimanali - Tieni un registro giornaliero o settimanale dei progressi per aiutarti a capire i progressi che hai già fatto con un progetto.

• Elenco di cose da fare - Ho un elenco di cose da fare generale, ma tengo anche un elenco di cose da fare separato per i progetti a cui sto lavorando in modo da ricordare quali cose devo ancora fare per un progetto. A volte lascio anche // TODO: elementi nel mio codice.

• Note sul progetto - Le cose che noto includono collegamenti a elementi di tracciamento / progetto, frammenti di codice, problemi riscontrati, decisioni prese, piani e descrizioni di potenziali soluzioni, elenco delle modifiche al codice, collegamenti alla directory del repository di codice, e-mail per il progetto e collegamenti a documentazione di progetto.

Quindi, ogni volta che torno a un progetto, posso aprire le mie note e quasi immediatamente posso vedere quanti progressi sono stati fatti sul progetto, quanto lavoro è rimasto da fare e persino vedere il mio flusso di pensieri.

Per progetti semplici, faccio questo:

1. Un semplice file README nella directory principale (che, quindi, finirà anche nel controllo della versione) in cui noto tutto ciò che viene visualizzato durante lo sviluppo: cose da fare, bug, miglioramenti / idee. Questo è il primo file che leggerò nel caso dovessi mettere il progetto sul back burner.
2. TODO / FIXME / XXX commenti
3. Uso spesso anche ToDoList