Accueil > conférence > Bon code vs Mauvais code

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 :

manifesto

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!

Publicités
Catégories :conférence Étiquettes : , ,
  1. 29/05/2010 à 19:52

    Merci pour le résumé ! A priori, il semble que cette conf soit un résumé succinct du bouquin de Uncle Bob sorti en 2009 : « Clean Code » (disponible en français : « Coder proprement »). Je vous le conseille à tous, ce bouquin est excellent.

  2. Jul
    13/06/2010 à 07:15

    Aye j’ai vu.
    C’est pas mal et y a du bon. Mais 2 choses pour moi restent parfois dures a appliquer :
    1. Les tests unitaires. C’est tres bien je suis d’accord avec lui sur la « peur » de modifier le code, mais les developper peut avoir un cout important a la creation et modification. Je ne parle de fonction simples genre tri/add/delete etc. mais de code vraiment complexe. Le cout est vraiment important si on parle de « vrais » test unitaire avec des mock objects et tout.
    2. Longueur des fonctions et decoupage : parfois c’est juste long, complique et y a rien a y faire la classe fait pleins de choses et decouper ne menera qu’a plus d’interraction entre objets et au final on sera encore plus embrouilles qu’avant.

  3. 13/06/2010 à 20:12

    Merci Jul pour ton commentaire.

    1) Effectivement je pense aussi qu’on ne peut pas tout tester unitairement.
    J’aimerais faire un billet là dessus : Peut-on tout tester? Doit-on tout mocker?

    Dans mon cas, ayant souvent travaillé sur des CMS ou des Portails, je ne pense pas qu’il y ait un interêt à mocker l’API de ces outils … Du coup, il ne reste plus grand chose à tester unitairement et la grande partie des tests se fait à l’exécution en navigant sur le site en développement.

    2) Y’aurait-il une possibilité que tu postes une de tes méthodes longues et compliquées et on tenterait de la découper ?

  4. Jul
    14/06/2010 à 02:05

    1. Oui, en fait je serai interesse de voir des trucs sur les TU sur certaines architectures, ca doit etre possible mais je ne vois pas comment (ou alors vraiment couteux et relou).
    2. Pardon je me suis plante je voulais ecrire « classes » et non methodes, je remet :

    « Longueur des methodes et decoupage : parfois c’est juste long, complique et y a rien a y faire la classe fait pleins de choses et decouper ne menera qu’a plus d’interraction entre objets et au final on sera encore plus embrouilles qu’avant. »

  5. 13/07/2010 à 15:28

    C’est clair qu’il vaut le coup d’être vu le monsieur !

    @Jul : Ce que j’entends dire régulièrement c’est que le temps d’écriture des tests, ça devrait être 50% du temps de développement (vivi !). Si tu teste correctement ton appli, tes tests ont même plus de valeurs que ton code : si tu as des bons tests, qu’ils passent alors tu as une bonne appli !
    Et d’ailleurs, tes méthodes complexes, c’est très certainement les premières choses à tester avant de les modifier, c’est à dire avant d’introduire d’éventuelles régressions !

    Ce qui ressort des manifestes agiles et craftmenship, c’est qu’on ne négocie plus sur la qualité !! C’est MAL ! Même s’il faut livrer demain. On est pro où on ne l’est pas là est la question !

  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :