Utiliser l'organisation d'une société comme indicateur de la qualité de son code

Ce matin, je lisais un retour de Jolicode sur le symfonyLive 2015 quand, au détour d'un article, une phrase de Bastien Jaillot a eu un fort retentissement en moi :

Tout logiciel reflète l’organisation qui l’a créée

-- Bastien Jaillot

Je n'avais jamais perçu cette évidence, mais maintenant qu'elle m'est servie, je ne peux qu'en être convaincu.

Quand une société n'est pas claire avec ce qu'elle veux, qu'elle se laisse porter par le vent, où que trop de personnes ont un pouvoir sur l'orientation d'un logiciel, alors ce logiciel va partir dans tous les sens, et devenir un magma sans tête.

A l'inverse, quand une société pose un objectif clair, et que tout le monde vise cet objectif en concevant le logiciel permettant d'atteindre cet objectif, alors la conception de ce logiciel restera simple.

Utiliser l'organisation de la société comme indicateur de la qualité du code produit.

atoum adopte semver

Pour ceux qui ne le savent pas encore, j'utilise atoum pour mes tests unitaires.

Il s'agit d'un framework de tests unitaire qui a été le premier à mes yeux à bousculer PHPUnit avec une approche novatrice, orienté objet, avec des performance impressionnante, un système de mock très simple et efficace.

Depuis 3 ans, j'évangélise cet outil partout où je passe, même chez M6Web, pour qui je travaille depuis 1 an 1/2.

Toutefois, lors de cette dernière expérience, je me suis confronté aux limitations de la Rolling Release, à savoir que lorsque l'on déploie atoum sur plein de projets, on emporte continuellement des nouveautés qui influent sur le résultats. Tant que ces changements sont compatibles avec l'existant, cela ne pose pas plus de problème que ça. Par contre, lorsqu'un changement apporte une régression, il suffit d'utiliser des outils d'intégration continue, et c'est tout les déploiements d'une société qui peuvent se retrouver bloquer.

On peut débattre sur la manière de nommer le changement : regression, correction, évolution, mais à partir du moment où le résultat de l'exécution d'une suite de tests change uniquement parce que l'outil de test à évolué, je considère qu'il y a régression.

En conséquence, je milite depuis plus d'un an pour qu'atoum soit taggé, de manière à pouvoir stabiliser la version d'atoum utilisée pour un projet.

Et depuis ce matin, cet espoir est comblé puisque la release 1.0.0 de atoum a été délivrée ! J'irais même plus loin en disant qu'atoum va désormais être taggé selon l'approche semver !

Et si vous avez lu l'article de Julien, vous aurez donc vu que nous sommes désormais 2 RM (Release Manager), Ivan Enderlin et moi-même, à gérer ce versionning qui va très fortement faciliter l'intégration d'atoum via composer, et qui, je l'espère, sera une véritable aide à sa démocratisation.

Me voici donc embarqué dans la team atoum, ce qui est un grand honneur qui m'est fait, et qui me donne désormais envie de m'investir un peu plus dans son développement.

La mode du bashing

Depuis de longs mois, voire des années, je me fais souvent la même réflexion en observant les réactions des gens lors des discussions de comptoir : le bashing est tendance.

Il me semble que, par le passé, je voyais plus de débats où on défendait son avis, on mettait en avant les qualités pour justifier ses choix. Mais maintenant, il est plus "hipe" de dénigrer les choix de l'autre, voire l'autre (Argumentum ad hominen).

Récemment, nous avons eu l'exemple des libraires qui affichent leur "choix" de ne pas proposer le livre de V. Trierweiler, alors que la réalité est sûrement tout autre.

La réalité est que ces libraires sont certainement plus intéressés par l'impression de supériorité intellectuelle qu'ils vont donner à leur clientèle que par une profonde conviction éthique.

Hier soir, j'étais témoin d'un énième Apple bashing et j'ai eu cette même impression que la personne cherchait à se donner une image de supériorité en dénigrant les "idiots qui vont jeter un téléphone qui a à peine 1 an et jeter par la fenêtre des centaines de $ parce qu'Apple change le nom du modèle".

N'avons-nous pas été témoins de la même chose lors de la sortie du Galaxy S3 de Samsung (je n'ai pas suivi la sortie du S4) ou lors de la plus récente sortie du Nexus 5 ?

De même, autant pour Apple que pour Samsung ou Google, cela représente une partie des utilisateurs, qui n'est pas une majorité. Il va y avoir une forte demande du dernier modèle sortie, au moment de sa sortie, mais la majorité des gens qui vont changer n'ont pas le dernier modèle depuis 6 mois.

Je suis concerné par cette dernière affirmation, puisque j'ai acheté un iPhone 4S à sa sortie, et je compte m'acheter le 6 dès qu'il sera sorti, mais je serais donc passé d'un iPhone 3G à un 4S, puis d'un 4S à un 6, soit à chaque fois 2 modèles totalement ignorés.

Bref, pour en revenir au sujet initial, nous faisons tous des choix, c'est ce qui nous construit et qui fait de nous une personne unique au monde. Mais vivons avec nos choix et nos idées, pour nous, nos proches. N'attaquons pas les idées et les choix des autres pour se donner l'impression d'être "mieux" ou "supérieur".

Au revoir CleverAge

Certes, ce titre est vu et revu, mais il parle toujours de la même chose.

Donc, pour la troisième fois en 2 ans 1/2, je change d'employeur.

Toutefois, autant j'ai quitté Prestaconcept pour me lancer un nouveau défi et j'ai quitté TEA parce que je ne m'y sentais pas à ma place, autant cette fois ci, c'est plutôt pour assainir ma situation.

Depuis le mois de juin 2013, je suis un employé de CleverAge, mais je suis en délégation chez M6Web. Du coup, je ne me sens pas complètement intégré dans cette incroyable famille qu'est CleverAge, tout en étant pas un employé de M6Web, pour qui je m'investi jour après jour.

J'en étais à ce stade de réflexion quand M6Web a décidé d'ouvrir des postes de lead-developpeur. Comme dans les faits, je travaille pour M6Web depuis 1 an, et je trouvais donc qu'il était plus naturel de faire le choix de M6Web. Et c'est ainsi que, début octobre, je quitte CleverAge pour devenir interne M6Web.

Je tiens tout de même à insister sur le fait que CleverAge est une excellente société, avec de très bons projets et des collaborateurs de qualité. Si vous êtes à la recherche d'une société qui sait prendre soin de ses collaborateurs, je ne peux que vous encourager à prendre contact avec eux.

Mais maintenant, je suis pleinement tourné vers l'avenir avec M6Web, et sur le projet RisingStar pour commencer ;)

Code reviews : just do it

Ce titre est volontairement repris sur l'article d'Éric, car il s'agit d'une réponse/complément que je ne me voyais pas faire en commentaire.

Ayant travaillé chez TEA par le passé, j'ai donc la connaissance de la manière dont se passent les code reviews chez TEA, et je suis en phase complète avec les avantages listés par Éric : augmentation de la qualité et partage de l'information.
Il y a non seulement le fait que plusieurs yeux, plusieurs esprits passent sur un code, une problématique, et il y a donc un échange constant sur ce qui est fait, pourquoi et comment. Mais il y a aussi et surtout une vraie communication qui se met en place entre les développeurs, réduisant l'effet de chapelle (une seule personne capable d'intervenir sur un code) et augmentant la cohérence générale d'un projet.

J'ai également constaté un effet de bord plutôt sympathique, car lorsque l'on sait que son code va être relu, on s'oblige à le faire beaucoup plus propre et on s'interdit les petits raccourcis crades qu'on pourrait utiliser dans un moment de flemme, d'une manière semblable à ce qui se passe quand on code pour un projet open-source.

Depuis, je travaille en délégation chez M6Web, dans l'équipe Replay, et nous avons mis en place le même système : tout développement se passe dans sa branche propre, amène à la création d'une PR, et il faut la validation de 2 personnes de l'équipe (sur 8 personnes) pour que la PR soit mergeable.
Toutefois, ce système peut rapidement trouver ses limites. Chez M6Web, La focalisation par projet est moindre, du fait du nombre de personnes composant l'équipe et de l'organisation de la structure, ce qui implique que nous travaillons sur une grosse dizaine de projets en parallèle et cela a des impacts :

  • Il est souvent compliqué intellectuellement de switcher de projet et de problématique pour relire le code de quelqu'un d'autre.
  • Savoir quelles sont les PR en attente sur une dizaine de projets est un vrai exercice d'équilibriste qui demande, à l'état brut, de parcourir les PR en attente sur tous les projets pour voir celles qui sont en attente.

Au final, nous avons un phénomène d'empilement des PR qui pénalise l'avancement quotidien.

Toutefois, tout ceci n'est qu'un problème d'organisation, et il vaut mieux trouver comment contourner les limites plutôt que de faire marche arrière sur la code review automatique.

Je ne manquerai pas de vous faire un retour des solutions que nous avons mises en place.