La qualité est un voyage

pas une destination.

C’est par ces mots que se termine la conférence Qualité du code source et l’intégration continue des collaborateurs de Xebia. Il est bon de rappeler que la qualité ne peut pas être quelque chose qui s’enclenche en un geste, ni même qu’elle se termine.

Au cours de ma carrière, j’ai souvent été surpris par le peu de qualité fournie sur les projets, tant au niveau du code source que de la documentation. Et ne parlons pas des tests ou de l’intégration continue, concepts encore trop souvent inconnus chez certains éditeurs.

Mais instaurer la qualité sur un projet existant ou dans une société n’est pas chose aisée. Xebia le détaille d’ailleurs très bien sur les dernières diapositives de son exposé.

Pour ma part, je dirais que la plus grosse difficulté n’est pas sur la technique, puisque qu’après tout, si d’autres sociétés le font, tout le monde peut le faire, mais sur les individus et la motivation.

En effet, si les participants au changement ne connaissent pas ces pratiques, ils peuvent douter de leurs biens fondés, de la facilité de mise en place, des gains de productivité et qualité et de l’impact direct sur leur travail.

Imaginez, vous demandez à des développeurs, souvent en place depuis plusieurs années de :

  • changer leur façon de développer, cela pourrait laisser penser qu’ils ne savent pas développer,
  • écrire des tests unitaires et d’intégration, ce qui va leur demander plus de temps, et donc faire baisser leur productivité,
  • suivre leur projet sur un serveur d’intégration et corriger toute erreur en priorité si le cas se présente, ce qui signifie que corriger un serveur de build est plus important qu’une fonctionnalité métier,

Il est clair que si l’on évoque ces trois points, la qualité du code source et l’intégration continue ne semblent pas apporter de productivité aux développements, bien au contraire.

Mais lorsqu’on connait les 3 points suivants, les premiers commentaires semblent bien négligeables, face aux avantages accumulés :

  • Un développeur passe 80% de son temps à lire du code et 20% à en écrire, il a donc tout intérêt à avoir un code lisible et rapidement compréhensible, pour diminuer son temps de lecture et augmenter son temps d’écriture,
  • Les tests permettent d’être informé de la moindre régression dans le code et de modifier à loisirs et sans doute du code existant afin de l’améliorer,
  • Le serveur de build informe, en temps quasi-réel, de l’état du projet et des tests pour l’ensemble des acteurs du projet, afin de corriger une erreur au plus tôt et de ne pas attendre d’être en production pour corriger une faille passée au travers des tests métiers,

Pour une société qui ne maitrise aucun des points cités précédemment, les gains de productivité peuvent atteindre 300%, voire plus si le code est réellement catastrophique ou si l’intégration de nouveaux développeurs est importante. Vous me direz alors, 300%, c’est énorme. En fait à y réfléchir, ces 300% ne sont pas très important, c’est principalement la productivité de départ qui est très faible. Car bien souvent, si vous n’avez pas de qualité du source code ou d’intégration continue, vous empilez les bugs, vous multipliez les copier-coller de peur de modifier l’existant, vous passez votre temps à lire et vérifier une implémentation…

Mais rappelez-vous, pour mettre en place les bons process de développements, le plus important n’est pas la technique, c’est l’accompagnement au changement. Soyez sur d’avoir les bonnes personnes pour vous aider.

Publicités

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 :