Software Craftsmanship

Tous les développeurs ne se retrouvent pas dans la mouvance agile souvent du fait que ce mouvement ne met pas suffisamment le focus sur l’excellence technique et les pratiques d’ingénierie y amenant. Certains professionnels de l’agilité ne portent pas suffisamment d’importance à ces pratiques d’ingénierie.

Chez Invivoo, nous avons l’intime conviction qu’il ne peut pas y avoir d’agilité dans une organisation IT sans adopter les pratiques et les valeurs promues par le Software Crafsmanship. En effet, l’objectif de ces organisations est de construire des logiciels apportant de la valeur à ses clients au bon moment et pouvant s’adapter facilement aux changements. Dans cette industrie, la majeure partie des produits est constituée de code. Si l’on veut que ces produits logiciels s’adaptent facilement, il est nécessaire de s’armer avec des pratiques et des techniques qui permettent de garantir la flexibilité du code en permanence tout en ne dégradant pas la qualité de ce dernier.

De la même façon, ne s’intéresser qu’aux aspects techniques pour rendre une organisation IT agile n’est pas suffisant. Il est aussi nécessaire d’apporter des cadres méthodologiques, une nouvelle culture plus orientée produit avec toutes les pratiques et outils qui permettent l’application de cette culture au quotidien.

Pour toutes ces raisons, dans l’industrie logicielle, l’agilité et le Software Craftsmanship sont pour nous indissociables et autant utiles l’un comme l’autre pour rendre une organisation plus d’agile dans sa globalité.

Un produit logiciel peut être facilement adaptable dans le temps si le code sous-jacent a une architecture évolutive, s’il est testable et testé pour garantir sa qualité au cours du temps et si son « ownership » est partagé par l’ensemble de l’équipe de développement. Ces caractéristiques permettent d’arriver à un code que l’on peut qualifier d’agile.

Le Software Craftsmanship prône l’utilisation d’un certain nombre de pratiques agnostiques à tout langage ou écosystème et qui amène à avoir un code agile. Parmi ces pratiques, on peut trouver les suivantes :

• Le Pair Programming et le Mob Programming (plus récemment appelé « Ensemble Programming ») qui consistent respectivement à travailler en permanence en binôme ou en équipe entière. Ces approches ont la vertu de développer le partage de l’ownership du code au sein de l’équipe. Ainsi, telle partie du code n’est pas la propriété d’un membre de l’équipe, mais de l’ensemble de l’équipe. La maîtrise de l’ensemble du code est bien plus partagée. De plus, cela permet un regard plus critique sur le code produit, un partage des bonnes pratiques, et ainsi une culture de l’excellence technique plus présente
• La revue de code qui, au même titre que le Pair Programming, mais dans une moindre mesure, permet d’améliorer l’ownership du code par l’ensemble de l’équipe
• La bonne connaissance et la veille permanente de l’équipe sur les bons principes de design et d’architecture du code amenant à ce que l’on appelle le clean code. Parmi ces derniers, on peut citer les principes SOLID dans le cadre d’un développement orienté objet ou l’architecture hexagonale garantissant une bonne isolation entre le code métier et le code technique, et ainsi une meilleure évolutivité du code
• La pratique du TDD (Test Driven Development) consistant à construire le code de notre produit logiciel à partir des tests en respectant le cycle suivant : Développement d’un test échouant / Développement du code minimum pour faire passer le test / Refactoring de l’ensemble du code produit. Le TDD a une double vertu : faire émerger un design de code simple, évolutif et testable (à condition de maîtriser les principes de design de code) et prévenir toute régression le plus tôt possible
• La pratique du BDD (Behavior Driven Development) consistant à spécifier un besoin métier sous la forme d’exemples écrits en langage naturel et compréhensible par tous les intervenants d’un projet : de l’expert métier au développeur, ces exemples servant aussi au développement des tests d’acceptance. Le développement du produit logiciel est ainsi guidé par les comportements métiers attendus de celui-ci. La pratique du BDD est souvent liée à celle du TDD avec ce que l’on appelle le double loop TDD où la boucle de réalisation d’un test d’acceptance inclut plusieurs boucles de TDD
• La pratique du refactoring en continu qui consiste à remanier très régulièrement la structure interne du code pour le rendre plus simple, maintenable et évolutif sans détériorer la fonctionnalité qu’il est sensé assuré. Cette pratique permet de limiter la production de code legacy. Elle nécessite une bonne connaissance et un apprentissage de l’équipe des techniques de refactoring et des code smells (c’est-à-dire les mauvaises pratiques de code)
• Le DDD (Domain Driven Design) qui rassemble des patterns stratégiques et tactiques pour mieux appréhender le domaine métier sous-jacent à un produit logiciel et remettre ce métier au cœur de la conception et du développement