de rien, content que cette lecture ai pu t'aider à mieux comprendre les tenants et aboutissants de cette position
En effet, cela reste un recueil et des points de vues liées aux expériences de l'auteur et des personnes qu'il a pu interroger, à chacun de se forger sa propre opinion basée sur son expérience, mais en tant que débutants cela reste une bonne base pour pas partir sur de fausses bonnes questions et faire à peu près bien dès le début, pour des plus expérimentés, cela permet de confronter les points de vue et peut être mieux viser la cible inatteignable du code idéal pour tous
Ce que je rejette c'est d'indiquer comme règle d'or de la qualité de commenter, commenter et toujours commenter, cela fait s'écarter des vrais problématiques et du coup n'aide pas à l'amélioration du code
Mais je ne dis pas non plus "Fais du code propre et ne mets aucun commentaire", mais plutôt "efforce-toi à ne pas avoir recours aux commentaires" (autrement dit "concentre toi sur l'écriture de bon code"), dès lors qu'en tout dernier recours, la mort dans l'âme, tu écris ton commentaire qui aurait pu être éviter mais que tu as vraiment tout essayé avant et sais que ça pourra être (ou plutot sera) revu ultérieurement, alors là OK, l'amélioration du code est en bonne voix
C'est justement parcequ'il est utopique d'écrire naturellement et toujours un code le plus parfait possible (ne serais que pour une question de temps mis à notre disposition pour le faire) qu'une autre règle liée à la qualité est de "laisser la place un peu plus propre qu'on l'a trouvée" afin justement de maintenir/améliorer la qualité du code au fur et à mesure que "le projet s'expanse"...et comme rien n'est simple, il faut faire avec une règle qui se défend très bien car touche directement au résultat pour le client final (celui qui paie !) : "le moins on touche au code, le mieux on évite les régressions" ==> c'est pourquoi qu'une autre règle doit être appliquée : "Tester, tester, retester encore" (un jeu de tests unitaires complet et corrects doit être maintenu pour permettre un refactoring aux risques maîtrisé....et le petit plus comme cela à déjà été dit ici, les test unitaires restent une très bonne documentation du code en ce sens où ils permettent de savoir exactement ce que doit ou pas faire telle ou telle méthode)
==> la qualité est vraiment un tout !!
Partager