Bon code vs Mauvais code

On est samedi, il pleut, et pourtant le moral est bon car je viens de visionner la présentation de Robert C. Martin a.k.a Uncle Bob : Bad Code, Craftsmanship, Engineering, and Certification.

Robert C. Martin has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, OO, Patterns, UML, Agile Methodologies, and Extreme Programming.

– Antony : Alors JVeille, de quoi ça parle cette conférence qui t’a tant enthousiasmé?

– JVeille : Mon cher Antony, dans cette conférence on parle principalement de code, le mauvais code et le bon code. D’ailleurs, la conférence commence par le mauvais code avec la projection du film suivant (attention les yeux, ça pique) :

– Antony : Wahoo mais qu’est-ce que c’est?!

– JVeille : C’est un exemple de la vraie vie comme je les affectionne tant. C’est un fichier, de plusieurs milliers de lignes de code!!!! Un fichier comme jamais je n’aimerais en voir de mes propres yeux.

– Antony : Tu m’ettones, mais alors Uncle Bob, il dit quoi? Il a des solutions pour éviter d’en arriver là ?

– JVeille : Bien sûr, il a des conseils, des astuces et devine quoi, il nous les donne :

La règle du boyscout

Lorsque nous ouvrons un fichier de code source, nous devons le laisser plus propre que nous l’avons trouvé.

Si on l’applique, la qualité du code s’améliore progressivement.

Quelle est la taille idéale d’une méthode?

La mauvaise réponse selon Uncle Bob est : « La taille de l’écran ». Comprenez par là, autant de ligne que l’écran peut afficher en une seule fois.

– Antony : Mais alors, qu’elle est la bonne réponse?

– JVeille: Selon Uncle Bob, tu dois procéder comme suit : Pour chaque méthode, tu dois extraire des portions de code et en créer des méthodes privées, tu recommences l’opération tant que tu trouves des méthodes à alléger. Tu peux bien sûr t’aider des options de ton IDE préféré pour le faire.

– Antony : Ah oui j’utilise Eclipse, je sélectionne quelques lignes de code, clic droit, Refactor, Extract Method … et dans la fenêtre je mets le nom de la nouvelle méthode, je modifie le nom des paramètres, etc …

– JVeille : Tu peux aussi faire « SHIFT+ALT+M » pour aller plus vite au lieu de prendre ta souris! Et si un jour je t’enlève ta souris comme le préconise Rosh Osherove, tu feras comment?

Combien de paramètres pour une méthode?

Selon Uncle Bob, zéro c’est le mieux! Plus sérieusement, jusqu’à 3 ça va, tout dépend du besoin. Par contre, ce qu’il faut à tout prix éviter c’est d’avoir 2 paramètres de type booléen :

execute(id, true, false);

Va falloir se rappeler que fait le premier booléen et que fait le deuxième.

Et au sujet des noms de méthodes?

La règle d’Uncle Bob est : La longueur du nom d’une méthode est inversement proportionnelle à sa visibilité.

Plus concrètement, une méthode publique, d’une classe qui sera manipulée très souvent, doit avoir un nom court : FileOutputStream.close();

Par contre, une méthode privée, peut très bien avoir un nom long, qui facilite la compréhension et dont l’utilisation et la visibilité sont limitées : sortObjectsByNameAndDate(objects);

Mais encore ?

Uncle Bob aborde les thèmes classiques du Test Driven Development, la couverture de code, l’intégration continue, les revues de pairs.

Il projette le Manifeste de l’Artisan Développeur :

Uncle Bob vous fixe comme défi de faire en sorte  que les cellules d’Assurance Qualité ne trouvent pas de bugs (QA should find nothing!).

Pour finir, les thèmes abordés très rapidement car le speaker semblait manquer de temps :

Comment convaincre ses collègues? Faites votre travail du mieux que vous pouvez en espérant que vous inspirerez vos collègues à faire de même.

Comment convaincre son manager? Posez-lui la question suivante : « Veux-tu qu’on fasse du bon travail ou du mauvais travail? »

Raccourcissez les cycles de développement.

Source Code is the design : Oubliez le MDA & l’UML. Le code source c’est du texte, s’il est bien fait, c’est la meilleure des documentations.

Je vous souhaite un bon visionnage, ça en vaut la peine!