Après mon post sur « Centre de développement agile chez Nespresso : retour d’expérience par Guillaume Vial » je continue mon compte rendu de « GenevaJUG – Soirée Quickies pour le 4ème anniversaire » par une bonne connaissance, Nicolas PERU (@benzonico ou linkedin… Et attention à ne pas prononcer perOU ;), avec le sixième et dernier quicky de la soirée. Vous pouvez le revoir sur la vidéo officielle de la soirée sur YouTube (2:00:56).

Ce qui est certain, c’est qu’il a soigné son teasing le Nico, avec ce titre des plus intrigants !… Mais de quoi va-t-il bien nous parler ???

Cependant, à posteriori, maintenant que je connais la fin de l’histoire et ce qu’il arrive au héros, je trouve ce titre judicieux.

Nicolas commence par nous parler de « conventions implicites » qui, par définition, ne sont pas explicitées mais qu’il ne vous viendrait pas à l’esprit de transgresser.

Pour ma part, quand j’aborde ce sujet en formation, je commence par poser la question :
– « Qui dort dans le même lit que sont conjoint ? »
puis je continue ainsi :
– 
« Que ceux dont le père ou la mère leur a explicitement dit de le faire gardent la main levée »
…
Et tout le monde baisse la main !

• Les attributs membres en fin de classe
• La CamelCase… Mais cette convention n’est pas des plus lisibles : pourquoi donc ne pas utiliser les « _ », à commencer par les tests : voici_un_exemple_de_nom_de_methode_test.

Alors là, j’applaudis !

Depuis… 2002 j’ai pris cette habitude, car à l’époque il y avait un outil en C++ (et oui, je viens de là 😉 qui prenait les noms des méthodes de test, et générait un rapport ainsi :
la méthode « test_quelque_chose » générait «le comportement ‘quelque chose’ est testé »

Depuis j’ai conservé cette habitude pour nommer mes tests :
– test_leNomDeMaMethode_unContexte
– test_leNomDeMaMethode_unAutreContexte
– test_transfertLignesDeCompte_bug34415

Cela permet de
1) respecter la convention JUnit (textXXX)
2) d’avoir exactement la même casse pour le nom de la méthode et,
3) d’aller dans le sens de faire émerger un DSL.
Donc je « plussois » !

• La notion de « Broken Beans », quand on ne respecte pas la ségrégation entre getter et setter, ce qui viole l’encapsulation…
  • Soit avec des getter et setter qui possèdent un comportement. Ou touche là à la notion d’Anemic Domain Model
  • Soit en empilant les normes et usages

Il y a quelques temps, je suis tombé sur un getter qui faisait un appel service, 
avec un update (set) dans la foulée !… Heureusement que, en phase de debug, j’ai eu la curiosité de dépasser « le protocole » (cad ne pas prêter attention aux conventions, de base ici) et d’aller jeter un oeil dans l’implémentation de la méthode ! Dans ce cas, je prône que toutes les méthodes s’appellent m1, m2, m3… Au moins on sait qu’on doit aller voir dedans !

Puis Nicolas aborde quelques « biais psychologiques »…

Je pense qu’il a du faire une traduction littérale, mais en français on parle de biais «cognitifs »

Il commence par le « group think » (1/4) qui caractérise notre métier en raison de l’esprit de communauté très marqué, et de leaders forts.

Aller, je prend ce compte rendu comme une occasion de creuser les biais cognitifs.

D’après Wikipédia sur la « Pensée de groupe » :
« Un mode de pensée dont les gens usent lorsqu’ils sont profondément impliqués dans un groupe uni, quand le désir d’unanimité des membres outrepasse leur motivation
à concevoir d’autres solutions de façon réaliste. »

Effectivement, ne sommes nous pas dans un JUG, une communauté de javateux (et je m’inclus dedans… ce soir ;), qui prônent le CamelCase, contrairement aux rubistes par exemple ;))

Nicolas parle ensuite du « status quo » (2/4) et de la résistance au changement que l’on peut rencontrer au quotidien.

D’après Wikipédia sur le « biais de statu quo » :
« Au niveau du comportement, on appelle biais de statu quo la résistance au changement, une attitude mentale qui fait apparaître quelque nouveauté comme apportant plus de risques que d’avantages possibles»

Ce point m’a d’ailleurs toujours étonné : ce décalage entre les « early adopters » que l’on peut rencontrer dans notre métier (les « geeks » pour le commun des mortels, pour « les autres» 😉 
et l’inertie propre à bon nombre de projets informatiques.

Puis il revient à des aspects plus techniques (en apparence) avec la « dependency injection» : il promeut la pratique de « constructor injection » par opposition à la « field injection »

Le principe de « dependency injection » n’est certes pas un biais cognitif… 
Du moins pas dans ses fondements, mais il est vrai que ce principe à tendance à se traduire par l’overdose méthodique et systématique de XML !… En ça on pourrait parler de biais 😉

C’est exactement pour cela que je suis allergique aux configurations XML, contrairement à celles dans le langage cible qui, pour peu qu’il soit typé, permettent une auto description, et donc de guider le chaland dans sa configuration : un unique constructeur avec 2 paramètres… y a pas moyen de se tromper… Contrairement à cette « bip » de balise XML qui contient très certainement certains attributs, mais aussi un nombre inconnu de balises filles, qui ont la bonne idée d’avoir elle même des filles qui elles même…
Cela touche aussi à la rapidité du feedback : dés la compilation, au lieu d’attendre le déploiement…

Mais cet exutoire est totalement hors-sujet 😉

Cette « disgression technique » sur l’injection de dépendance est pour illustrer le « Framing Effect » (3/4) ou « biais de cadrage » : 2 présentations différentes d’un même problème amène 2 résolutions différentes

D’après Wikipédia sur le « biais de cadrage » :
« Le cadrage est l’action de présenter un « cadre cognitif » comme approprié pour réfléchir sur un sujet.
Ce cadrage peut avoir un effet sur le raisonnement 
et conduire à des choix différents en fonction de la façon dont le problème a été formulé »

Puis de conclure avec le « biais d’ancrage » (4/4).

D’après Wikipédia sur le « biais d’ancrage » :
« l’ancrage désigne la difficulté à se départir d’une première impression »

Dans le cas d’une rencontre ou d’un entretien, par exemple, il est fréquent de dire « on a une chance unique de faire une première bonne impression » 😉

Mon doggy bag

… Ou ce que je retiens de cette session

En conclusion, un joli défi que Nico a relevé : attaquer les développeurs sur ce qu’ils ont de plus sensibles, leurs « habitudes », leurs conventions, et cela sous l’angle des « biais cognitifs ».
Je salue la prise de risque !

Une réussite à la vue du temps imparti. En effet, la première fois que j’avais vu une présentation sur le sujet, c’était à XP Day France par Laurent Bossavit… En une heure !
Nicolas a réussi à en introduire 3 en 10 minutes.
Pour information, la page Wikipédia sur les biais cognitif en recense une quarantaine!… Bonne lecture 😉

Soyons conscients de nos dysfonctionnements et challengeons nos conventions…

Comme j’aime à le dire :

« Les règles sont faites pour être dépassées, les valeurs pour ne pas s’égarer ».

Pour ma part, ce quicky me conforte dans ma conviction que 
la plus grande force du développement logiciel, est aussi sa plus grande faiblesse : 
l’être humain.

Et maintenant, quel va-être ton prochain défi Nico ?…

Parler des Biais Cognitifs à softshake’14… A moins que ce soit sur la Reactive Programming ou un quicky sur les MOOC comme Coursera 😉

PS : Merci à Nicolas pour sa relecture… Si vous avez des questions, il est disponible via twitter (@benzonico) ou linkedin.