Thread by @jesuisundev

Un commentaire intéressant sur la vidéo de ce matin.

Quelqu'un qui m'expliquait que le clean code c'est bien beau, mais que son équipe/entreprise n'avait pas le temps pour.

Deux / trois remarques sur cette réalité et comment essayer de changer les choses.

Pour le management, il faut présenter le clean code comme un investissement.

Quelque chose qui va être rentable dans le temps. Et surtout afficher les vraies problématiques de livrer en production du mauvais code. En particulier pour un client important qui fait de l'argent.

Il faut parler leurs langages. Parler de rentabilité, satisfaction client et productivité. Le management s'en fout complètement de tes principes SOLID.

Pour l'équipe de dev, il faut parler de l'hypothèse de la vitre brisée.

En résumé, si tu commence à laisser et "vivre avec" des sataneries dans le code, toute la base de code va fatalement devenir l'enfer sur terre.

Le wiki l'explique mieux que moi : fr.wikipedia.org/wiki/Hypoth%C3…

Et en laissant ça arriver, leur vie va devenir un enfer. Chaque jour sera une souffrance à courir après des deadlines, de la merde jusqu'au cou. Personne ne veut ça et c'est facile à faire visualiser.

Si ces changements ne peuvent malgré tout pas être faits d'un coup, alors proposez d'y aller progressivement.

Demander du temps pour du refactor d'endroit en particulier. S'investir pour inspirer les autres à te rejoindre dans l'effort de nettoyage. Il suffit d'une personne !

Si ces changements mettent du temps à être accepté alors rappeler régulièrement les dégâts en cours.

À chaque crash, bugs et retards inhérents au mauvais code, tu seras là pour rappeler ce qu'il faudrait faire.

Enfin, si après tout ça, rien ne bouge ça va finir par te rendre fou. Tu vas aller au travail avec une boule. Tu ne veux pas passer 8h par jour à nettoyer de la merde.

Il est temps de regarder pour un changement de poste dans une entreprise qui adhère à tes idées.