Come ricordi dove nel tuo codice vuoi continuare la prossima volta? [chiuso]

Risolvo qualsiasi test unitario non funzionante. Se passano tutti, allora ne scrivo uno nuovo.

All'inizio di ogni giorno, ho un file di testo chiamato Todays Goals.txt, e poi ogni giorno aggiungo la data in questo modo.

Venerdì 25/02/2011 Obiettivi

Quindi scrivo ogni progetto su cui sto lavorando, e cosa devo fare oggi, o per completarlo.

Poi alla fine della giornata, scrivo cose da fare domani.

Questo processo giornaliero mi aiuta a ricordare esattamente quello che devo fare e ad assicurarmi che ogni giorno sia ben pianificato.

Fondamentalmente non dimentico mai su cosa sto lavorando. Visual Studio si apre all'ultima file su cui stavi lavorando, oppure, non chiudo mai Visual Studio e non faccio altro che ibernare.

Metto NotImplementedExceptions alle astrazioni / implementazioni che non sono necessariamente importanti per continuare a sviluppare quello su cui stavo lavorando.

Metto un sacco di TODO nel mio codice, ma non come hai detto tu. Li metto dove so che un certo approccio sarebbe più bello / più performante, ma non necessario al momento. Ciò fornisce una buona indicazione per me e gli sviluppatori futuri su dove c'è spazio per miglioramenti.

Usando l'Elenco attività di Visual Studio, puoi facilmente visualizzare tutti i luoghi in cui hai lasciato queste indicazioni e puoi persino aggiungerne di personalizzati.

UPDATE:

" HACK :" è anche bello quando scrivi qualcosa che funziona, ma non ne sei affatto soddisfatto.

Alla fine di ogni giornata, scrivo nel mio libro di esercizi su ciò che ho realizzato quel giorno, su ciò che mi aspetto di realizzare il giorno successivo e su ciò che è ancora da fare.

All'inizio di ogni giornata, mi riferisco ai miei appunti del precedente per rinfrescarmi con quello che devo fare. Poi, trascorro qualche altro minuto a creare più note in base a ciò che è accaduto da quando sono partito per capire cos'altro devo fare e quali sono le mie priorità.

Trovo che questo mi aiuti a rilassarmi e a lasciarmi andare alla fine della giornata e ad accelerare all'inizio. Inoltre, quando arriva il momento delle recensioni annuali o trimestrali, devo solo fare riferimento alla mia cartella di lavoro per determinare cosa stavo facendo nel periodo in esame.

In una delle interviste in "The Masterminds of Programming", (penso che sia stato Guido van Rossum, creatore di Python), l'intervistato ha dichiarato di aver aggiunto un commento di //HIER al posto in cui ha finito l'ultima volta. "HIER" è olandese (?) Per questo e lo sceglie perché se si cerca quella stringa è improbabile trovare altre occorrenze

Di gran lunga, il mio modo preferito è attraverso TDD. È abbastanza ovvio dove ti trovi quando la tua suite di test fallisce.

Tuttavia, non tutti i progetti consentono TDD, quindi tendo ad interrompere il codice con un commento non commentato, dove ho lasciato.

// Some Comment

Becomes Some Comment // Which Produces Some Fatal Error

Questo errore fatale assicura che io non lasci intatto quel codice prima di rilasciarlo.

Infine, posso sempre controllare i miei vcs per vedere cosa è cambiato dal mio ultimo commit e questo mi darà una buona idea di dove dovrei andare dopo ...

Uso due tecniche moderne molto sofisticate con una curva di apprendimento molto ripida:

• Non spegnere il computer . Vai a casa e la mattina dopo vedrai sullo schermo il luogo esatto in cui hai smesso di hackerare ieri. Ma i rischi di perdere il checkpoint sono molto più alti se si parte per una vacanza.

• Lascia un errore di compilazione e controlla un altro ramo. Quindi il tuo codice C ++ dovrebbe essere simile a questo:

  for (i=0; i<N; i++){
    int j = i + oh, no, my boss wants me to fix text on the front page!
    why? why should I do it?  Jimmy could have done it faster, but
    of course, my office is closer to the boss', and he doesn't want to
    take longer walks, that lazy fat bastard...
  

  In questo modo il progetto non verrà creato all'accensione del computer o al ramo in cui si stava eseguendo lo sviluppo attivo. Il tuo compilatore mostrerà la riga esatta e il file dove ha incontrato i tuoi rant.

Queste tecniche mi hanno aiutato a riconoscere il posto in cui ho lasciato lo sviluppo, e sono supportate da studi completi e dall'esperienza di molti programmatori in tutto il mondo. Ti suggerisco di provarli.

Questa è ora una funzionalità integrata in Visual Studio 2012 in cui è possibile sospendere e riprendere lo spazio di lavoro. Suspend eseguirà un'istantanea dei file aperti, i punti di interruzione, la lista di controllo, gli elementi di lavoro ecc. E il ripristino lo riporterà indietro. In sostanza, l'intero contesto di lavoro viene salvato e riprenderà esattamente come è stato lasciato.
link

Un breve video che mostra la funzione è qui
link

Il mio preferito attualmente è il tag speciale // NEXT: . Insieme all'esploratore TODO ReSharper è molto facile da scoprire e mantenere.

Conservo un log di sviluppo per ogni iterazione in un sottoprogetto di documenti non costruiti in Visual Studio; l'ultima riga nel registro è sempre l'attività successiva.

Inoltre, non chiudo molto spesso lo studio visivo, ma metto il computer in standby

Per trovare ciò di cui ho bisogno per tornare immediatamente, di solito metto un commento in:

//TODO: figure out why the widget doesn't unfrob properly

Lo circondo con linee vuote e attira facilmente la mia attenzione quando lo rivedo. Per i problemi a lungo termine che dovrò tornare alla fine, uso una direttiva del compilatore Delphi che ti permette di emettere messaggi durante la compilazione:

{$MESSAGE WARN 'This method is not yet implemented'}

Non sono sicuro che altre lingue possano farlo ...

Gli elenchi TODO non funzionano quando parliamo di tornare a un progetto di mesi prima. I commenti nel codice non funzionano bene per me, è semplicemente troppo facile ignorare o ricordare se ho completamente terminato il progetto X e dovrei cercare prima di tutto. E se hai una squadra più grande con ogni persona che ha la sua frase TODO ... ugh.

Poiché la mia giornata inizia con update / merge / build, qualcosa che ho provato in qualche occasione è di inserire un errore di compilazione intenzionale in un file (ma non di verificarlo). Sfortunatamente, ho smesso di farlo dopo che ho avuto un improvvisato drop-in in ufficio che voleva vedere una demo di qualcosa che ho lavorato la settimana prima. "Ecco, fammi aprire questo ... aspetta ... cosa significa ... ok allora ..."

Quindi, mi sono trasferito da quello a scrivere un caso di test intenzionalmente fallimentare.

Lascio emacs con il codice su cui stavo lavorando sullo schermo per il giorno successivo.

A volte scrivo una nota non compilabile nel codice che mi dice cosa fare dopo.

Per un widget davvero complicato in cui sono suscettibile di essere confuso riguardo alle cose, scriverò note su un quaderno o come commento.

Se solo per mantenere il mio posto in un file mentre eseguo una ricerca, a volte mi abusa dei punti di interruzione.

Per tenere traccia del fine settimana in cui mi trovavo, mi lascio una nota con il numero del problema del bug tracker.

Stai usando un sistema di controllo della versione? Se sì, allora dovresti impegnare le tue modifiche alla fine della giornata e descrivere cosa hai fatto e cosa devi fare dopo nel commento. E se no, allora perché non sei?

Non riesco a chiudere Visual Studio e ad ibernare Windows alla fine della giornata.

Sono uno dei pochi che si riavvia ogni notte (ancora su Win XP al lavoro e sento che funziona meglio.), quindi creo un task Outlook con un promemoria impostato per il mattino successivo. Posso mettere il nome del file, una copia della riga di codice o abbastanza di una nota per farmi sapere cosa stavo facendo.

Aiuto per diverse cose:

• Cerco il testo "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" che presenta i vantaggi che il codice non può eseguire (sia esso codice compilato o interpretato), quindi non posso mancarlo. Inoltre, quel tag è rosso vivo per me grazie a synesthesia , quindi è davvero facile individuare anche in una grande porzione di codice.

• L'IDE riapre i file nella posizione in cui erano aperti tutti (e quali linee erano evidenziate / punti di interruzione), così posso ricordare rapidamente cosa stavo facendo.

• Riesco a vedere nella mia lista delle cose da fare quale problema stavo tentando di risolvere / funzionalità da implementare.

Dato che non hai detto che devi compilare il codice per compilare effettivamente sia il debug che il rilascio, un trucco che faccio spesso è:

#if DEBUG
#error "YOU LEFT OFF HERE"
#endif

Molto difficile da dimenticare. Altrimenti, inserirò un avvertimento #pragma nel codice in modo che appaia ogni volta che compili.

Uso diversi trucchi:

• Posiziona @@ nei commenti di codice o in un documento per le cose che devono essere eseguite nell'iterazione corrente ma non immediatamente. Nessun codice o documento lascia la mia macchina se contiene @@.

• Quel posto specifico che devo continuare a lavorare domani mattina segnalo con @@ QUI. Questo è raramente necessario perché il mio IDE si aprirà dove chiudo prima, e puoi anche dì a Word di farlo .

• Tutte le cose che dovrebbero essere aggiustate / aggiunte in un secondo momento vanno in un sistema di tracciamento dei bug o nei documenti di progettazione.

E sei sicuro che il tuo Visual Studio non ricordi l'ultima posizione su cui stavi lavorando? "Sospensione del lavoro con Visual Studio 2012" dice che può essere fatto nel 2012 (Google per Visual Studio start "lasciato fuori" )