Oncle Bob (Monsieur Robert Cecil Martin pour les autres), mentionne :

Si tu penses commenter ton code, c’est sans doute que c’est mal conçu, alors réécris-le, ne le commente pas.

Cette phrase prend une grande place dans le rôle du professionnel TI que nous sommes.

Une devise de scout,

Nous quittons le camp plus propre que lorsque nous sommes arrivés.

Je suis dans le coaching Agile depuis quelques années, et il ne passe pas une journée où je dois répéter ces devises :

« Ce code est mal fait, je vais ajouter un commentaire pour le prochain qui va essayer de le comprendre » me dit un développeur tout souriant.

« Heu! Non, réécris le code, ne le commente pas. »

« Argh! la documentation n’est pas à jour » me dit l’analyste « Je vais laisser une note. »

« Merci du commentaire, maintenant mets-le à jour, et n’écris pas ta note. »

« OK!, si l’utilisateur active le bouton ‘non’, c’est parce qu’il doit changer la valeur d’un champ. Mais comment saura-t-il?  » demande le PO. « Ce n’est pas grave, nous allons écrire un texte dans l’écran pour l’expliquer » mentionne le rédacteur.

« Heu! Non, concevez la bonne interface graphique. »

Il n’y a pas de propriété intellectuelle, ce qui appartient à la communauté (projet, organisation, etc.) peut être modifié par celle-ci en tout temps. Vous allez me dire que vous n’avez pas le temps, bien alimentez votre carnet de dettes, car c’est bien ce que c’est.

« Fred, j’ai trouvé quelque chose pour bonifier ton texte. Je vais te laisser une note en bas dans la zone des commentaires. » Me mentionnez-vous. « Heu! non, modifies-le toi-même et laisse faire le commentaire. » Je vous répondrai bien, si ce n’est des contraintes de l’outil 😉