Sonar 2.0 is just out and adds very interesting stuff. It focuses especially on architecture and OO metrics, which were the missing part of the metrics puzzle in previous releases.
Martin Fowler a publié un article sur son blogue qui présente les symptômes d’un mal qu’il nomme le Scrum Flasque (Flaccid Scrum). J’ai vu les symptômes qu’il cite se manifester à plusieurs reprises lors de divers mandat en clientèle chez des entreprises faisant une transition vers Scrum:
They want to use an agile process, and pick Scrum
They adopt the Scrum practices, and maybe even the principles
After a while progress is slow because the code base is a mess
Comme le mentionne Fowler, Scrum est un processus mettant l’emphase sur des techniques de gestion de projet et qui, contrairement à Xtreme Programming, ne met délibérément pas de l’avant des pratiques d’ingénierie spécifiques. Selon lui, les gens adoptant Scrum ont tendance à croire que si le processus ne parle pas des aspects techniques, c’est qu’ils sont moins importants que le reste. Ainsi, rapidement, « No Big Design Up-Front » devient «No Design At All ». Et s’ensuit une dette technique qui ne s’arrête plus de grandir…
Que faire pour inverser la vapeur? Les pratiques XP (le Test-Driven Development, le refactoring, le pair programming, le collective code ownership) sont une réponse possible et souhaitable. Toutefois, selon mon expérience, elle prennent du temps à assimiler, tout particulièrement dans les grandes organisations ayant souvent connu un fonctionnement plus directif par lequel les développeurs ont l’habitude de recevoir d’un architecte une grande partie des détails de la solution à réaliser. On demande la plupart du temps à ces développeurs d’apprendre TDD alors qu’ils vivent la pression d’un projet et qu’ils ont parfois des difficultés à reconnaître les symptômes d’un mauvais design et qu’ils maîtrisent mal les bases mêmes de l’orienté-objet. Comment faire pour aider les développeurs ainsi conditionnés à prendre en main une plus grande part du travail de conception? Et comment faire pour aider les équipes adoptant une approche agile à minimiser et contrôler leur dette technique?
Pourquoi ne pas introduire des code reviews? Non, non, ne fuyez pas! Je ne parle pas d’un processus de revue de code à la Fagan, extrêmement rigide et coûteux. Je parle plutôt d’un processus léger de revue par les pairs, et en partie au moins automatisé. On ne parle presque pas des revues de code dans le monde agile parce qu’elles semblent souffrir de cette image désuète, dépassée et poussiéreuse. Une image de lourdeur tout ce qu’il y a de moins agile…
Pourtant, les outils d’inspection du code automatisés deviennent de plus en plus sophistiqués et aptes non pas seulement à détecter les erreurs de style, mais aussi à mettre en lumière les duplications, les code smells de toutes sortes, les failles dans la couverture de test, etc. Par exemple, dans le monde Java, il faut désormais considérer un outil comme Sonar, libre et gratuit, comme un indispensable, une aide monumentale à la visualisation et l’identification de la dette technique s’adressant à tous les intervenants d’un projet. Sonar consolide les données recueillies par plusieurs autres outils, comme Findbugs, Checkstyle, PMD, Cobertura et bien d’autres, les digère et les présente sous une forme compréhensible et grandement utile.
En dehors des outils, pourquoi ne pas inclure dans notre définition de done une revue de code « humaine » pour traiter en équipes des problématiques plus pointues comme le respect des requis, la qualité des tests, le respect du cadre architectural, etc. La compagnie SmartBear a produit un très bon papier présentant des recommandations dans l’adoption un tel processus. Et d’autres outils émergent également pour supporter ce type léger de revue de code par les pairs à même l’IDE (Jupiter, ReviewClipse, Rietveld, CodeCollaborator, etc.) permettant par exemple d’associer des commentaires avec des lignes ou blocs de code. Certains de ceux-ci s’intègrent également avec les systèmes de gestion des sources pour automatiser la revue de code avant ou après un commit.
Je crois fermement aujourd’hui que les revues de code, autant humaines qu’automatisées, sont un outil complémentaire et nécessaire durant l’apprentissage des techniques XP par une équipe de développement. Elle sont une occasion en or pour un coach technique d’enseigner le repérage des code smells et une aussi belle occasion pour les membres de l’équipe d’apprendre en observant le travail des autres, de mieux communiquer, de se sentir comme faisant partie d’un groupe uni et organisé et de se sentir engagés dans le développement d’un logiciel de qualité supérieure. Allez-y! Redonnez du tonus à votre Scrum!