Bonnes pratiques
Clean Code

Aujourd'hui, je vais te montrer les pires bouts de code que j’ai jamais vus. Des sataneries qu'il ne faut surtout pas produire !


Partagé par Benoit GANTAUME
il y a presque 4 ans
5

Benoit GANTAUME il y a presque 4 ans
Voilà un article qui fait à la fois rire et pleurer pour bien commencer la semaine.
Quelqu'un d'autre a du retour sur Code Complete ?
Charly Laurent il y a presque 4 ans
J'ai eu l'occasion de lire Clean Code et Code Complete, et c'est vrai que Code Complete est très intéressant pour coder proprement. Il traite d'autres aspects de la programmation également, comme le design. Un autre livre qui m'a beaucoup fait progresser sur ce sujet, c'est Refactoring de Martin Fowler.
Emmanuel Riche il y a presque 4 ans
Le code du module qu'il ne voulait pas touché ressemble beaucoup à du code que j'ai refactorisé pendant mes congés pour un ami développeur qui a une façon bien singulière de coder... Il y avait tous les ingrédients de la satanerie: duplication de code, pas de boucle mais des enchainements de if/else, 1000 lignes de code pour la construction d'une requête SQL pas si complexe que ça et tout ça en PHP sur du Joomla.
Ben vous savez quoi? Je crois que détruire ce code pour un code propre, testé et évolutif m'a vraiment procuré beaucoup de plaisir !
Sergio Mazzoleni il y a presque 4 ans
J'ai lu Clean Code de Robert Martin (Uncle Bob pour les intimes) pour la première fois en 2017. Depuis, je le relis à peu près une fois par an en me demandant si j'ai bien appliqué ce que j'avais retenu lord de ma dernière lecture, et j'ai vraiment le sentiment d'avoir amélioré la qualité de mon code depuis lors. De plus, je trouve que c'est un bouquin assez fun à lire et il s'applique à la plupart des langages (les exemples sont en java, mais ça se transpose facilement). Tout développeur devrait l'avoir lu au moins une fois selon moi
Marc Tourneux il y a presque 4 ans
J'ai bien aimé aussi Clean Code. Beaucoup de bon sens.
J’ai essayé d'introduire gentiment quelques principes présents dans ce livre dans les règles de codage de ma société actuelle : fonctions avec 5 arguments max, ne dépassant pas 250l... (Beaucoup moins contraignantes que dans le livre !)
Je m’attendais à un peu de résistance, mais je me suis retrouvé face à un refus total d’ajouter ces règles. Manifestement, avoir des fonctions de 1000 lignes ou des fonctions avec 25 arguments qui sont trimballés à travers plusieurs classes, ça ne gêne pas plus que ça certaines personnes... Et il ne faudrait surtout pas leur rajouter des contraintes.
Avez-vous déjà rencontré ce type de refus ?
Cela vaut-il la peine de défendre sa cause ? Où vaut-il mieux fuir ?
Benoit GANTAUME il y a presque 4 ans
Salut,
Par personnellement, mais j'ai vu ça en coaching d'équipes.
Fuir est une option rapide.
Défendre sa cause est plus long et plus impactant sur à terme. Mais il faut en avoir la patience et l'envie.
Si tu aimes le côté évangéliste, c'est intéressant à faire. Si tu veux juste coder dans de bonnes conditions, tu as probablement plus vite fait de changer d'environnement.
Marc Tourneux il y a presque 4 ans
Salut,
Je n'ai pas pris la peine de défendre mon point de vue car je suis le principal développeur. Les personnes opposées étaient les chefs de projet, qui ne touchent que très ponctuellement au code... et qui étaient beaucoup intéressées à définir la place de l'accolade pour le "if" (retour à la ligne ou pas ?! ça c'est un grand débat !)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Le désenchantement du logiciel
Afficher la ressource
Le TDD n'est pas du testing
Accéder à l'épisode
Live - Comment augmenter sa rémunération de 50%
Accéder à la vidéo
Engagez-vous qu'ils disaient avec Stan Leloup
Accéder à l'épisode
Quoi de neuf les devs ? Numéro 44
Afficher la ressource
Artisan Développeur utilise des cookies afin de t'offrir les meilleurs services. En poursuivant ta navigation, tu acceptes l’utilisation de cookies. En savoir plus