Comment gérer un TODO dans une demande de tirage?
Lorsque j'examine les modifications apportées à une demande d'extraction, je tombe parfois sur un commentaire avec une note "TODO" qui peut être présente pour différentes raisons, dans notre cas, principalement à cause de:
- la solution utilisée pour résoudre un problème peut être améliorée mais nécessiterait beaucoup plus de temps d'investissement. Un auteur a choisi une solution plus rapide mais a commenté qu'une meilleure option est potentiellement disponible
- il existe un code temporaire pour contourner un bogue existant qui devrait être corrigé bientôt
Sachant que TODOs restent généralement dans la base de code pendant toute la durée de vie de la base de code, comment dois-je réagir en cas de pull request? Comment puis-je demander poliment de l'éviter, ou si c'est vraiment justifié, comment puis-je m'assurer que l'auteur du RP en assurera le suivi plus tard dans le futur?
Lorsque vous dites qu'ils "restent généralement dans la base de code pendant toute la durée de vie de la base de code" dans votre équipe/département/organisation, tenez compte des points suivants:
- Notez-le dans votre DoD que les balises
TODO,FIXMEou similaires doivent être évitées. - Utilisez un outil d'analyse de code statique tel que SonarQube pour marquer automatiquement la génération instable.
- Autorisez-les temporairement si et seulement si un ticket correspondant existe dans votre outil de suivi des problèmes. Ensuite, le code peut ressembler à
TODO [ID-123] Description ...
Comme mentionné dans mon commentaire , la dernière déclaration n'a probablement de sens que dans un environnement qui ne laisse pas les tickets pourrir (par exemple si vous suivez une politique zéro bug ).
Personnellement, je pense que TODOs sont parfois raisonnables, mais il ne faut pas les utiliser de manière excessive. Tiré de Robert C. Martin's "Clean Code: A Handbook of Agile Software Craftsmanship" (p. 59):
TODOs sont des travaux qui, selon le programmeur, devraient être effectués, mais pour une raison quelconque, ils ne peuvent pas le faire pour le moment. Cela peut être un rappel pour supprimer une fonctionnalité obsolète ou un appel pour qu'une autre personne examine un problème. Il peut s'agir d'une demande à quelqu'un d'autre de penser à un meilleur nom ou d'un rappel pour effectuer un changement qui dépend d'un événement planifié. Quoi que puisse être unTODO, ce n'est pas une excuse pour laisser un mauvais code dans le système.
TODO eux-mêmes ne sont pas mauvais. Je suis un grand fan de ne jamais aller plus d'une couche, et de toujours résoudre 1 problème par ticket de suivi.
J'utilise souvent TODO ou FIXME comme un moyen de me rappeler que j'avais besoin ou que je voulais revenir pour résoudre un problème.
Par exemple, je peux appeler add (a, b) et ajouter un TODO pour refactoriser la méthode add. Je ne veux pas travailler sur la méthode add maintenant, mais je veux y revenir.
Ainsi, dans une demande de tirage, vous verrez TODO ou FIXME. J'utilise FIXME par exemple pour alerter les autres développeurs de zones de code dont ils ont la responsabilité, avec lesquels je ne devrais pas jouer. Par exemple, FIXME add ne peut pas accepter les nombres négatifs.
Pour contourner le problème de ne pas être vu ou ignoré, j'utilise un script qui répertorie toutes les lignes TODO FIXME et DEGUG. Et cela est ajouté au message de validation.
Il est difficile d'ignorer un message de validation de 400 lignes qui est tous TODO. Les gens les corrigent donc, soit en touchant déjà le code en question, soit en créant de nouveaux tickets et en corrigeant le code de problème de manière autonome.
Pour être juste, je m'assure également que chaque projet dispose d'un temps de nettoyage de code intégré. Oui, be peut être prêt à être lancé le 15, mais nettoyait le code du 15 au 30. (cela semble étrange, mais si vous avez déjà géré un produit, vous savez que si vous essayez d'avoir des tâches de faible visibilité avant le lancement, vous ne serez jamais autorisé à y accéder. Quelque chose d'autre deviendra prioritaire.)
Si votre projet suit les éléments en attente dans le code source avec des commentaires TODO, vous devez l'autoriser.
Le fait que la présence d'un commentaire TODO dans la demande d'extraction soit un bug, vous devez vous dire que le suivi des éléments en attente dans le code source est une mauvaise idée. Les choses ont tendance à se perdre ou à être ignorées de cette façon. Maintenant, si vous parlez d'une demande de tirage vers une "fourchette de travail", la situation est différente. Une "fourchette de travail" n'est que cela - un travail en cours. Mais une fourchette comme celle-ci ne nécessite généralement pas de demande de tirage. Les "règles internes" suggérées ici concernent les demandes de tirage pour la branche master.
Règle maison n ° 1 - Tous les commits sur master devraient être prêts pour les tests, car master est construit quotidiennement après tous les check-ins. Ces commits doivent également inclure tous les tests supplémentaires requis.
Si le commentaire TODO est là parce que le code n'est pas terminé, ou que les tests ne sont pas terminés, ou que le code n'est en aucune façon prêt pour les tests, alors ce code appartient à une validation locale, pas à un tirer la demande. Appelez-moi quand c'est prêt.
House Rule # 2 - Toutes les informations concernant les problèmes en suspens sont stockées dans le suivi des problèmes. Tout. Notes, gribouillis, intuitions, peu importe.
Si le commentaire TODO se rapporte à un problème ouvert et n'est pas un correctif réel pour ce problème, alors ces informations appartiennent au suivi des problèmes. De cette façon, avant la fermeture d'un problème, toutes les informations peuvent être examinées et vérifiées, si nécessaire, pour vous assurer que le problème est réellement résolu.
Règle maison n ° 3 - Toutes les informations concernant les tâches de projet en attente appartiennent à la file d'attente prioritaire (ou quel que soit le nom de votre système).
Pour plus de précision, une tâche de projet en attente est quelque chose qui doit être fait dans le projet qui a une priorité définie, qu'il s'agisse d'un défaut qui a été découvert avant qu'il ne génère un ticket de problème, ou la mise en œuvre d'une exigence de conception spécifique, ou l'une des composants nécessaires de cette exigence.
Si le commentaire TODO est là pour dire que le nouveau code aura un impact sur une tâche en attente, ou pour signaler quelque chose d'autre dans la base de code qui doit être examiné et qui a été découvert lors de l'implémentation du nouveau code, alors cette information appartient à la file d'attente prioritaire, sur la tâche existante ou en tant que nouvelle.
Règle n ° 4 de la maison - Les suggestions appartiennent à la boîte à idées (ou autre).
Si le commentaire TODO suggère un changement dans la conception ou l'implémentation du logiciel, alors ces informations appartiennent à la boîte à idées du projet, ou "vNext", ou "Design Notes", ou tout ce que vous avez pour ce type de chose.
House Rule # 5 - TODO les commentaires ne sont pas autorisés dans le code source. PÉRIODE.
Si vous vous en tenez à cette règle, vous n'aurez pas à vous soucier du suivi de quoi que ce soit.
Il arrivera qu'il y a des demandes d'extraction qui ne sont pas parfaites. En ce moment, je fais un travail qui peut être fait "assez bien" dans le temps disponible, mais pas parfait. Donc, je soumets une demande de pull, je mets TODO avec des commentaires aux bons endroits dans le code, et en même temps j'ajoute une autre demande de changement pour changer les choses de "assez bien" en "parfait".
Cette nouvelle demande de changement peut ensuite être priorisée et elle sera traitée lorsqu'il s'agit de l'élément de priorité la plus élevée. S'il est décidé qu'il doit être parfait en ce moment, alors ce sera la prochaine chose remise.
Maintenant votre question: "Comment puis-je demander poliment de l'éviter, ou si cela est vraiment justifié, comment puis-je m'assurer que l'auteur du PR le suivra plus tard dans le futur?" Avec ce que je décris, cela semble plutôt idiot. Si j'ai le choix entre l'expédition tardive et l'expédition de ce qui est assez bon, ce n'est pas votre décision. Vous pouvez en parler à votre chef de produit si vous le souhaitez. Et "assurez-vous que l'auteur du PR fera le suivi"? Si vous avez une équipe, vous devez vous assurer que cela est enregistré dans vos systèmes, et j'espère que votre équipe est suffisamment bien organisée pour que les choses enregistrées ne se perdent pas, et quelqu'un le corrigera éventuellement, quand il n'y a pas d'articles de priorité plus élevée. N'oubliez pas, c'est un effort d'équipe.