Chez OCTO, nous considérons que le partage du savoir et des bonnes pratiques est un élément essentiel à l'épanouissement professionnel de chacun. Autrement dit, c'est sympa d'être une "Great Place to Work", mais c'est encore mieux d'être "Best Place to Grow". Dans la continuité de "Partageons ce qui nous départage", nous souhaitons diffuser régulièrement à l'extérieur d'OCTO les pratiques qui nous permettent de nous améliorer au quotidien.

Si les BOFs constituent l'événement principal pour partager nos retours d'expérience, on voit aussi régulièrement des OCTOs investir une salle de réunion durant la pause de midi pour aborder leur(s) sujet(s) de prédilection, dans le cadre d'un BBL, ou Brown Bag Lunch.

Je vous propose donc un retour sur notre BBL des Artisans Codeurs, qui nous réunit régulièrement sur le thème du mouvement Software Craftsmanship. Ce mouvement vise notamment à remettre en valeur le métier de développeur : nous pensons qu'être développeur est une carrière aussi prestigieuse que celle de chef de projet ou de consultant, et que le développement de logiciel est une activité complexe pour laquelle la qualité n'est pas négociable.

Afin de partager ces valeurs et de permettre  aux plus jeunes (et pas que les plus jeunes !) de progresser, il faut donner les moyens de faire cet apprentissage permanent.

Saison 1, Clean Code

La première saison de ce BBL s'achève et c'est l'occasion de résumer ce que nous avons partagé tout au long de cette année. Le concept est simple :

• Nous nous sommes retrouvés toutes les semaines pour progresser sur le sujet en prenant un livre de référence pour support.
• Semaine 1, discussion autour du thème abordé par le chapitre en cours
• Semaine 2, passage à la pratique avec, selon les cas, une proposition de code à challenger ou à refactorer, la découverte d'un langage ou d'une API, le tout au format Dojo Randori ou Kata.

Plusieurs ouvrages font office de référence sur le sujet, autant sur le métier de développeur (The Pragmatic Programmer, Clean Coders, etc.) que sur les techniques de développement (Clean Code, Code Complete, Refactoring, Working Effectively with legacy Code, etc.).

Nous avons choisi Clean Code, A Handbook of Agile Software Craftsmanship. Il s'agit d'un ouvrage collectif dirigé par "Uncle" Bob Martin, qui reprend pas à pas les bases des bonnes pratiques du développements logiciel.

Les sujets abordés (Nommage, Commentaires, Fonctions, Formatage, Gestion des erreurs...) peuvent paraître simples ou classiques, et les pratiques encouragées dans le livre semblent souvent relever du bon sens, mais en prenant le temps de se (re)poser les bonnes questions sur les bases, nous avons appris beaucoup :

• Comprendre une bonne pratique c'est une chose, savoir l'appliquer efficacement au quotidien en restant productif en est une autre.
• Ce partage nous a permis de voir que nous n'avons pas tous la même culture ou la même compréhension de certains concepts.
• Même pour les moins jeunes, cet exercice nous a été utile pour challenger et adapter nos pratiques. La pertinence de certains conseils de Bob Martin est même parfois plus percutante pour quelqu'un qui a quelques années de développement derrière lui et surtout de nombreuses passées à relire et modifier le code de quelqu'un d'autre.

Mais d'abord, en quoi ça consiste du code propre ? Bob Martin a posé la question à plusieurs "pointures" du petit monde du développement logiciel et le résume très bien en introduction de son livre, mais nous nous sommes néanmoins prêtés au jeu :

Si on ne devait retenir que quelques idées de ce livre :

• On n'écrit pas du code parfaitement propre du premier coup : les pratiques du TDD (Test Driven Development) et du Design Emergent sont essentielles pour y parvenir progressivement.
• Il est indispensable de prendre soin de son code afin d'éviter la dette technique, de limiter le phénomène des Broken Windows. Pour y parvenir, deux pratiques sont indispensables :
  • s'approprier le code collectivement : en ritualisant les revues de code et le pair programming, en évitant une répartition en silo des développements (un développeur doit toujours être capable de prendre la prochaine  story à développer sur le board)
  • la Boy Scout Rule : "le code que tu commiteras sera toujours plus propre que celui que tu as récupéré".
• Du code propre doit pouvoir se lire comme on lirait un journal : on doit facilement comprendre ce qu'il fait en lisant les gros titres. Pour cela, un bon découpage des classes et des fonctions est indispensable, en séparant les responsabilités et les niveaux d'abstraction, et en s'astreignant à un nommage explicite par exemple.

Il faut néanmoins savoir rester pragmatique et ne pas essayer d'appliquer à la lettre ces pratiques quelles que soit les circonstances. Il faut donc garder à l'esprit que des enjeux tels que les performances d'une application, ou tout simplement garantir la livraison des fonctionnalités peuvent nécessiter des concessions mineures.

Saison 2, "Bring your Own Code"

Après une saison riche en rebondissements du BBL Clean Code, il est temps d'enfiler nos blouses et d'entrer dans la salle d'opérations. Opérations à coeur ouvert sur des sujets au bord de l'arrêt cardiaque, débriefing post-opératoire ou encore séances pratiques d'apprentissage, le programme sera riche.

Le but de cette seconde saison du BBL des Artisans Codeurs est de se retrouver pour partager nos pratiques de "Clean Coders" sur des cas concrets.

Mode opératoire

• Tous les langages sont les bienvenus
• Traitement bimensuel en respectant la posologie d'Uncle Bob.
• Démarrer dès que possible.

Plusieurs exercices seront pratiqués :

Opération douloureuse

Du code qui  fait mal, ou tout simplement du code à améliorer : on cherchera des pistes d'amélioration tous ensemble et à initier un premier refactoring.

Partager nos fiertés

Les bonnes pratiques ont été appliquées sur un projet ? On partage ça, et on challenge le code en essayant de réaliser une mini story fictive.

Pour mesurer le tout : le nombre de WTF / minute, un indicateur empirique idéal !

Séance de travaux pratiques

Se former à de nouveaux langages, une nouvelle API, ou juste trouver la meilleure implémentation d'une problématique, le tout au format Dojo ou en binôme.

Ce format informel est facile à mettre en oeuvre : un seul pré-requis, un minimum d'engagement de la part des participants. Pourquoi pas chez vous ?