Dialogue presqu’imaginaire

[Nouveau Développeur] - Hello, je suis le nouveau développeur de l’équipe, tu peux me décrire votre architecture s’il te plait ?

[Tech Lead] - C’est une architecture hexagonale, c’est super tu verras: ça nous permet d’isoler notre logique métier du code d’infrastructure

[Nouveau Développeur] - C’est cool, ça ! Et il y a beaucoup de logique métier ?

[Tech Lead] - Non, pas vraiment, notre appli ne fait essentiellement que du reporting avec des requêtes de lecture en bdd mais comme c’est une best practice du DDD et qu’on fait tous du DDD dans la boite, on est parti dessus comme les autres.

[Nouveau Développeur] - En termes de layers, il y a donc des entités qui représentent les tables de la base de données ?

[Tech Lead] - C’est exact, des entités puis des classes métier sans annotations et puis des DTOs pour la partie REST. On a des services de mapping qui transforment ces objets des uns vers les autres.

[Nouveau Développeur] - Ce n’est pas trop compliqué à gérer du coup ?

[Tech Lead] - Que Nenni ! Car il n’y a pas vraiment de transformation à faire…et puis, on utilise Lombok pour générer tous les getters et les setters, ça nous simplifie la vie.

[Nouveau Développeur] - C’est une super idée ! Et comment vous configurez l’application ?

[Tech Lead] - On utilise Spring Cloud Config ! C’est génial !

[Nouveau Développeur] - Ah oui, j’en ai entendu parler! Vous mettez la config dans un repository Git alors ?

[Tech Lead] - Oui, exactement!

[Nouveau Développeur] - Il sert à d’autres applications le serveur de configuration ?

[Tech Lead] - Non, juste à nous

[Nouveau Développeur] - Il ne sert qu’à configurer votre application ? Dis-donc, vous vivez dans le luxe, ici!

[Tech Lead] - [RIRES] Oui, c’est ça! En fait, c’est une décision IT: chaque équipe doit avoir son serveur de configuration car c’est une best practice. Plus précisément, on a un serveur de configuration par environnement et par équipe!

[Nouveau Développeur] - Vous n’utilisez pas un repo git avec une branche par environnement alors ?

[Tech Lead] - Non, non: qui peut le plus peut le moins après tout…attends, je te montre notre configuration

[Nouveau Développeur] - Je vois: il y a une variable pour définir le niveau de logs, la connexion à la base de données et un lien vers un serveur…et c’est tout ?

[Tech Lead] - Oui, pour le moment…le niveau de logs qu’on peut changer dynamiquement, ça sera vachement pratique pour débugger en production!

[Nouveau Développeur] - A propos, combien d’instances de l’application sont déployées en production ?

[Tech Lead] - Deux, c’est largement suffisant pour le moment.

[Nouveau Développeur] - Comment vous avez-prévu de répercuter les changements de la configuration du coup ?

[Tech Lead] - Pour l’instant, on n’a jamais eu à le faire car la configuration est stable mais on est en train de regarder comment intégrer Spring Cloud Bus pour ça: il parait que c’est une bonne pratique dans ce type d’architecture.

[Nouveau Développeur] - Ah j’adore, j’ai toujours voulu jouer avec!

[Tech Lead] - Tu vas t’éclater alors…en plus, on va l’utiliser avec Kafka: comme ça, à chaque fois qu’on changera la configuration, nos instances seront rafraichies automatiquement!

[Nouveau Développeur] - Ah, ça c’est trop fun! Et c’est quoi ce serveur dans la configuration ?

[Tech Lead] - C’est un serveur Eureka pour faire du load balancing client

[Nouveau Développeur] - Génial! L’application communique avec beaucoup d’applications ?

[Tech Lead] - Non, juste avec une! Par contre, je connais une équipe qui gère une vingtaine de microservices. J’imagine que ça doit leur simplifier la vie pour les faire communiquer. Après tout c’est une best practice de chez Netflix!

[Nouveau Développeur] - Oui, j’avais lu un article sur ça il y a une dizaine d’années. C’est génial de pouvoir appliquer les best practices ici!

[Tech Lead] - N’est-ce pas ? Bienvenue dans l’équipe!

Vous est-il déjà arrivé de justifier des choix et des décisions en les qualifiant de “best practices” au détriment d’autres approches ? A moi, oui et j’ai également vu de nombreuses personnes tomber dans ce piège également.

Mais savez-vous ce qu’est une best practice ?

Posez donc la question à votre équipe pour voir ce qu’ils en pensent: demandez leur de définir ce qu’est selon eux une “best practice” et de fournir quelques exemples (sur des post-it par exemple).

Voici un condensé de définitions obtenues au sein d’une équipe de développeurs (tirées de la vie réelle):

On remarque que certains ont confondu définition et exemples: la raison est qu’ils ont eu du mal à savoir définir ce qu’était une best practice.

Ensuite, on voit qu’il est compliqué d’arriver à un consensus sur ce qu’est une best practice.

Est-ce que l’une de ces définitions correspond à ce que vous pensez ?

Voici quelques exemples fournis par cette équipe:

Cela correspond peut-être à des exemples que vous donneriez, n’est-ce pas ?

Demandez ensuite à ces mêmes personnes de définir ce qu’est un pattern, par opposition à une best practice et de fournir également quelques exemples de patterns.

En tant que développeurs, nous utilisons des patterns tous les jours, ça ne devrait donc pas poser de problème.

Voici les définitions données par ces mêmes développeurs:

Tiens, il y a beaucoup moins de définitions on dirait: y-aurait-t’il un consensus ? Pas vraiment on dirait.

Certains voient un rapport avec les best practices: soit c’est la même chose, soit c’est mieux (défini)!

Y-a-t’il une définition qui correspond à celle que vous donneriez ici aussi ? Ou alors en avez-vous une autre en tête ?

Voyons à présent les exemples donnés par l’équipe:

Ici aussi, pas beaucoup d’exemples, on en retrouve même certains dans les best practices. Il semble en effet que la différence entre best practices et patterns n’est pas très claire.

Alors, une best practice c’est la même chose qu’un pattern ?

Chez Labs, on estime que non et on utilise les définitions suivantes pour éviter de les confondre:

• Best Practice

une best practice est quelque chose que vous recommenderiez à quelqu’un de toujours faire, quel que soit le contexte.

Dans certains contextes (rires), la définition d’une best practice inclut la notion de contexte. Je ne recommande pas ce type de définition car “best” peut facilement s’interpréter comme “il n’y a pas d’autre choix”.

• Pattern

un pattern, c’est une pratique qui peut être répétée dans certains contextes, que l’on utilise pour résoudre un problème et qui a, en général, à la fois des avantages et des inconvénients.

Expliquez ces définitions à l’équipe et revisitez les exemples et définitions qui auront été donnés. Pour notre exemple:

“Est-ce que la revue de code est vraiment nécessaire lorsque l’on fait du pairing ou de l’ensemble programming ? Non ? Ce n’est pas quelque chose que je conseillerais toujours dans ce cas mais plutôt aux équipes qui ne pairent pas ou pour les développeurs n’appartenant pas à l’équipe qui créent des pull requests…”

“Est-ce que créer des features branches est une best practice ? Il existe pourtant des équipes qui font du Trunk Based Development et qui performent très bien. Dans quel contexte cela peut-il être bénéfique ou pas ?”

“Et les standups ? Sont-ils vraiment à conseiller à tout le monde ? Que pensez-vous des équipes qui travaillent en ensemble programming: quel serait leur intérêt de faire un standup puisqu’ils sont ensemble toute la journée ?”

Vous pouvez poursuivre avec les autres exemples et déplacer les post-its au fur et à mesure que l’équipe détermine si on parle réellement d’une best practice, d’un pattern ou d’autre chose.

Vous vous rendrez compte qu’à la fin de l’exercice, il ne restera pas (ou alors très peu) de post-its dans la colonne “Best Practices” tandis que la colonne “Patterns” sera bien remplie et qu’il restera des post-its qui ne sont ni l’un ni l’autre.

Quelles conclusions peut-on en tirer alors ?

Tout d’abord, qu’il est indispensable de se mettre d’accord sur des définitions communes si on souhaite que toute l’équipe soit alignée sur ce dont on parle.

Le second constat est que l’on a très facilement tendance à considérer comme une best practice ce qui n’est qu’un pattern en réalité. C’est-à-dire qu’on oublie de considérer le contexte. Par exemple, on réutilise une pratique qui a marché quelque part pour l’appliquer ailleurs sans vraiment se poser la question.

On doit donc toujours penser au contexte, aux avantages et aux inconvénients de nos pratiques ou de celles que l’on souhaite mettre en place. Il ne faut pas hésiter à comparer et, plus difficile encore, éviter de succomber trop facilement à la dernière pratique à la mode.

Quid des “bonnes” pratiques ? Là aussi, pareil, il y a beaucoup de sous-entendus à expliciter dans cette expression: demandez-vous dans quel contexte ces pratiques sont “bonnes”.

Avec notre définition, peut-il exister des best practices dans la vraie vie d’un développeur ?

Que pensez-vous de “toujours utiliser un repository pour stocker le code” ou bien “toujours utiliser un éditeur de code avec coloration de syntaxe” ? Ce sont probablement des exemples de pratiques à recommander quel que soit le contexte.

Avez-vous d’autres exemples en tête ?