Comment vous souvenez-vous où dans votre code vous souhaitez continuer la prochaine fois? [fermé]

Lorsque vous interrompez le travail sur du code (que ce soit parce que vous devez travailler sur autre chose ou partir en vacances ou simplement parce que c'est la fin de la journée), une fois que vous fermez ce projet Visual Studio, quelle est votre façon préférée de vous souvenir ce que vous voulez faire ensuite lorsque vous recommencez à travailler sur ce code.

Définissez-vous un signet Visual Studio ou notez-vous quelque chose comme // TODO: continue here next time ? Peut-être que vous avez un tag spécial comme // NEXT:? Mettez-vous une note collante sur votre moniteur? Utilisez-vous un outil sympa ou un plugin Visual Studio que je devrais connaître?

Avez-vous une astuce personnelle qui vous aide à trouver l'endroit dans votre code où vous vous êtes arrêté la dernière fois que vous avez travaillé sur votre code?

Je corrige les tests unitaires qui ne fonctionnent pas. S'ils passent tous, j'en écris un nouveau.

Au début de chaque journée, j'ai un fichier texte appelé Todays Goals.txt, puis chaque jour, j'ajoute la date comme ceci.

Vendredi 25/02/2011 Buts

Ensuite, j'écris chaque projet sur lequel je travaille et ce que je dois faire aujourd'hui ou le terminer.

Puis à la fin de la journée, j'écris des choses à faire demain.

Ce processus quotidien m'aide à me rappeler exactement ce que je dois faire et à m'assurer que chaque journée est bien planifiée.

En gros, je n'oublie jamais sur quoi je travaille. Visual studio s'ouvre de toute façon sur le dernier fichier sur lequel vous travailliez, ou je ne ferme jamais Visual Studio du tout et je passe juste en veille prolongée.

Je place NotImplementedExceptions sur des abstractions / implémentations qui ne sont pas nécessairement importantes pour continuer à développer ce sur quoi je travaillais.

Je place beaucoup de TODO dans mon code, mais pas comme vous l'avez dit. Je les place là où je sais qu'une certaine approche serait plus agréable / plus performante, mais pas nécessaire pour le moment. Cela donne une bonne indication pour moi-même et les futurs développeurs quant aux points à améliorer.

En utilisant la liste des tâches de Visual Studio, vous pouvez facilement afficher tous les endroits où vous avez laissé ces indications, et vous pouvez même en ajouter des personnalisées.

MISE À JOUR:

" HACK :" est également agréable lorsque vous écrivez quelque chose qui fonctionne, mais vous n'êtes pas satisfait du tout.

À la fin de chaque journée, j'écris dans mon classeur ce que j'ai accompli ce jour-là, ce que je m'attends à accomplir le lendemain et les choses qui restent à faire.

Au début de chaque journée, je me réfère à mes notes de la précédente pour me rafraîchir avec ce que je dois faire. Ensuite, je passe quelques minutes de plus à prendre des notes en fonction de ce qui s'est passé depuis mon départ pour comprendre ce que je dois faire d'autre et quelles sont mes priorités.

Je trouve que cela m'aide à me détendre et à me laisser aller à la fin de la journée et à monter en puissance au début. De plus, quand vient le temps des révisions annuelles ou trimestrielles, je n'ai qu'à me référer à mon classeur pour déterminer ce que j'avais fait pendant la période de révision.

J'utilise des outils de productivité pour VS. Avec cela, je peux épingler des onglets et les regrouper. = D De cette façon, je n'oublie jamais sur quoi je travaillais.

En plus de cela, j'ajoute également beaucoup de choses // TODO'sà mon code.

http://visualstudiogallery.msdn.microsoft.com/d0d33361-18e2-46c0-8ff2-4adea1e34fef/

Dans l'une des interviews dans "The Masterminds of Programming", (je pense que c'était Guido van Rossum, créateur de Python), l'interviewé a dit qu'il avait ajouté un //HIERcommentaire similaire à l'endroit qu'il avait terminé la dernière fois. "HIER" est néerlandais (?) Pour ici et il l'a choisi parce que si la recherche de cette chaîne, il est peu probable de trouver d'autres occurrences

De loin, ma façon préférée est par TDD. Il est assez évident où vous vous trouvez lorsque votre suite de tests échoue.

Mais, tous les projets ne permettent pas TDD, donc j'ai tendance à casser le code avec un commentaire non commenté de l'endroit où je me suis arrêté.

// Some Comment

Becomes Some Comment // Which Produces Some Fatal Error

Cette erreur fatale garantit que je ne laisse pas ce code intact avant de le publier.

Enfin, je peux toujours vérifier mes vcs pour voir ce qui a changé depuis mon dernier commit et cela me donnera une bonne idée de où je dois aller ensuite ...

J'utilise deux techniques modernes très sophistiquées avec une courbe d'apprentissage très abrupte:

• N'éteignez pas votre ordinateur . Rentrez chez vous et le lendemain matin, vous verrez à l'écran l'endroit exact où vous avez cessé de pirater hier. Mais les risques de perdre votre point de contrôle sont beaucoup plus élevés si vous partez en vacances.

• Laissez une erreur de compilation et passez à une autre branche. Donc, disons, votre code C ++ ressemblerait à ceci:

  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...
  

  De cette façon, le projet ne se construit pas lorsque vous allumez votre ordinateur ou que vous revenez à la branche où vous effectuiez le développement actif. Votre compilateur affichera la ligne exacte et le fichier où il a rencontré vos coups de gueule.

Ces techniques m'ont aidé à reconnaître l'endroit où j'ai quitté le développement, et sont soutenues par des études approfondies et l'expérience de nombreux programmeurs à travers le monde. Je vous suggère de les essayer.

Il s'agit désormais d'une fonctionnalité intégrée dans Visual Studio 2012 où vous pouvez suspendre et reprendre votre espace de travail. La suspension prendra un instantané de vos fichiers ouverts, points d'arrêt, liste de surveillance, éléments de travail, etc. et la reprise la ramènera. Fondamentalement, tout votre contexte de travail est enregistré et reprendra exactement comme vous l'avez laissé.
http://msdn.microsoft.com/en-us/library/ms181403.aspx

Une courte vidéo montrant la fonctionnalité est ici
http://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview/Visual-Studio-Ultimate-2012-How-to-multi-task- avec-mon-travail

Mon whay préféré actuel est le // NEXT:tag spécial . Avec l' explorateur TODO de ReSharper , il est très facile à découvrir et à entretenir.

Je garde un journal de développement pour chaque itération dans un sous-projet de documentation non construit dans Visual Studio; la dernière ligne du journal est toujours la tâche suivante.

Je ne ferme pas non plus Visual Studio très souvent, il suffit de mettre l'ordinateur en veille à la place

Pour trouver ce à quoi je dois revenir immédiatement, je mets généralement un commentaire dans:

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

Je l'entoure de lignes vierges et il attire facilement mon attention quand je le revois. Pour les problèmes à plus long terme auxquels je devrai éventuellement revenir, j'utilise une directive de compilation Delphi qui vous permet d'émettre des messages lors de la compilation:

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

Je ne sais pas si d'autres langues peuvent le faire ...

Les listes TODO ne fonctionnent pas lorsque nous parlons de revenir à un projet des mois précédents. Les commentaires dans le code ne fonctionnent pas bien pour moi, il est trop facile d'ignorer ou de se rappeler si j'ai complètement terminé le projet X et que je dois d'abord rechercher todos. Et si vous avez une plus grande équipe avec chaque personne ayant sa propre phrase TODO ... ugh.

Comme ma journée commence par la mise à jour / fusion / build, j'ai essayé à l'occasion de mettre une erreur de compilation intentionnelle dans un fichier (mais pas de l'archiver). Malheureusement, j'ai arrêté de faire cela après avoir eu un rendez-vous au bureau impromptu qui voulait voir une démo de quelque chose sur lequel j'ai travaillé la semaine précédente. "Ici, laisse-moi juste ouvrir ça ... attends ... qu'est-ce que ça veut dire ... ok alors ..."

Donc, je suis passé de cela à l'écriture d'un scénario de test intentionnellement défaillant.

Je laisse emacs avec le code sur lequel je travaillais à l'écran pour le lendemain.

Parfois, j'écris une note non compilable dans le code me disant quoi faire ensuite.

Pour un widget vraiment compliqué où je risque d'être confus à propos de certaines choses, je vais m'écrire des notes dans un cahier ou comme commentaire.

Si c'est juste pour garder ma place dans un fichier pendant que je poursuis une recherche, j'abuse parfois des points d'arrêt.

Pour garder une trace pendant le week-end où j'étais, je me laisse une note avec le numéro du problème du bug tracker.

Utilisez-vous un système de contrôle de version? Si oui, vous devez valider vos modifications à la fin de la journée et décrire ce que vous avez fait et ce que vous devez faire ensuite dans le commentaire. Et sinon, pourquoi pas vous?

Je ne ferme tout simplement pas Visual Studio et hiberne Windows à la fin de la journée.

Je suis l'un des rares à redémarrer tous les soirs (toujours sous Win XP au travail et je pense que cela fonctionne mieux.), Donc je crée une tâche Outlook avec un rappel défini pour le lendemain matin. Je peux mettre le nom du fichier, une copie de la ligne de code ou une note suffisante pour me faire savoir ce que je faisais.

Plusieurs choses aident:

• Je recherche le texte "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" qui présente les avantages que le code ne peut pas exécuter (qu'il soit compilé ou interprété), donc je ne peux pas le manquer. De plus, cette balise est rouge vif pour moi grâce à la synesthésie , il est donc très facile de la repérer même dans un gros morceau de code.

• L' IDE rouvre les fichiers à l'emplacement où chacun était ouvert (et quelles lignes ont été mises en surbrillance / points d'arrêt), afin que je puisse me souvenir rapidement de ce que je faisais.

• Je peux voir dans ma liste de tâches quel problème j'essayais de résoudre / fonctionnalité à implémenter.

Puisque vous n'avez pas dit que vous devez coder pour réellement compiler à la fois dans le débogage et dans la version, une astuce que je fais souvent est:

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

Très difficile d'oublier cela. Sinon, je mettrais un avertissement #pragma dans le code afin qu'il apparaisse à chaque compilation.

J'utilise plusieurs astuces:

• Placez @@ dans les commentaires de code ou dans un document pour les choses à faire dans l'itération en cours mais pas immédiatement. Aucun code ou document ne quitte ma machine s'il contient @@.

• Cet endroit spécifique que je dois continuer à travailler demain matin, je marque avec @@ ICI. Ceci est rarement nécessaire car mon IDE s'ouvrira là où je ferme plus tôt, et vous pouvez même dire à Word de le faire .

• Toutes les choses qui devraient être corrigées / ajoutées ultérieurement entrent dans un système de suivi des bogues approprié ou sont dans des documents de conception.

Et êtes-vous sûr que votre Visual Studio ne se souvient pas du dernier emplacement sur lequel vous travailliez? «Suspendre le travail avec Visual Studio 2012» indique que cela peut être fait en 2012 (le démarrage de Google pour Visual Studio est «laissé de côté» )