Il faut faire les deux mais à juste mesure et dans la limite du possible, on sait tous qu'un code propre, clair, net, concis, performant et sécurisé n'est jamais le fait du premier jet avec ses interrogations, ni produit dans des périodes de stress où le doute interne et le feu externe et la pression sont omniprésents.
En général on fait "pour que ça marche" pour valider un concept / une architecture. Une fois le concept / l'architecture validée, on fait "pour que ça marche mieux". Puis on fait "pour que ça marche pareil, mais plus sécurisé". Une fois les performances validées, on nettoie mais en général avant cette dernière phase, comme ça n'est pas demandé directement par le client, on est affecté à un autre projet, une autre mission.
Cette période de nettoyage est vu par la plupart de nos décideurs comme improductive et consommatrice de temps et donc d'argent, tout comme la phase de documentation soit dit en passant, on a tendance à faire ça lorsqu'il y a un audit qui pointe le bout de son nez, pas pour finaliser un projet.
Pourtant elle est bien réellement productive, mais à moyen / long terme. On peut penser qu'un cuisto n'est pas productif lorsqu'il nettoie sa cuisine et sort les poubelles au lieu de préparer des trucs à vendre et donc à acheter sur le tas, sauf que s'il ne le faisait pas, comment se passerait la journée du lendemain qui commencera dans un merdier ambiant avec l'odeur qui va avec ?
Par ailleurs, parfois un schéma vaut mieux qu'un long discours, d'où la nécessité d'un lien plutôt que 15 lignes de commentaires où on sent bien que celui qui l'a écrit s'embrouille tout seul face à la contrainte de l'unique langue qui n'aura pour terminaison que d'embrouiller davantage son lecteur.
Enfin, les commentaires sont également utilisés pour la sécurité juridique, une petite faute de grammaire ou d'orthographe par ci par là peut justifier un copier /coller illicite devant des autorités. C'est ce que m'a conseillé de faire mon avocate spécialisé dans les droits juridiques et numériques.
Partager