Si votre projet suit les éléments en attente dans le code source avec des TODO
commentaires, vous devez l'autoriser.
Le fait que la présence d'un TODO
commentaire 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. Le suggéré « House Rules » sont ici pour les demandes de traction pour le maître branche.
Règle maison n ° 1 - Tous les commits vers master doivent être prêts pour les tests, car master est construit quotidiennement après chaque check-in. Ces commits doivent également inclure tous les tests supplémentaires requis.
Si le TODO
commentaire 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 aucun cas prêt pour les tests, alors ce code appartient à une validation locale, pas à une demande de tirage. 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 TODO
commentaire 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.
House Rule # 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 TODO
commentaire 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 ces informations appartiennent à la file d'attente prioritaire, soit sur la tâche existante ou comme nouvelle.
Règle n ° 4 de la maison - Les suggestions appartiennent à la boîte à idées (ou autre).
Si le TODO
commentaire suggère un changement dans la conception ou la mise en œuvre du logiciel, alors cette information appartient à la boîte à idées du projet, ou "vNext", ou "Design Notes", ou tout ce que vous avez pour ce genre de chose.
House Rule # 5 - les TODO
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.