Savoir structurer

Introduction

« If you’re doing Extreme Programming the same way as you were doing it a year ago, you’re no longer doing Extreme Programming. » - Martin Fowler

De nos jours, et dans le monde informatique, la connaissance, le savoir dans son état brut, est une valeur boursière en chute libre. Le marché change, les normes changent, les clients changent, leurs besoins changent. Le savoir obtenu à un instant T est obsolète à T+1, alors que les choix, les priorités et les décisions prises à T-1 régissent les facteurs de succès ou d’échec d’un logiciel à l’instant T.

Je me souviens du bouquin Beautiful Architecture de Diomidis Spinellis, publié en 2009, qui énumérait les ingrédients permettant de créer une architecture applicative robuste, flexible, élégante et surtout maintenable. Des années après, le besoin n’a pas changé et le jargon ne fait que s’adapter aux nouvelles tendances de livraison se voulant Agile et collaboratives.

Faire le bon choix au bon endroit

Dans cette partie, nous aborderons les bases du DDD et des principes clés de l’orienté objet, tels que SOLID. Explorons les problèmes à éviter, l’approche d’architecture à emprunter, le rapport au code legacy à nouer afin de façonner...

Gestion de la dette technique

Voici une image qui m’avait marqué et fortement amusé à la lecture de l’ouvrage Clean Code - A Handbook of Agile Software Craftsmanship de Robert C. Martin, plus connu sous le surnom d’Uncle Bob.

Code Quality KPI : WTFS/m (WTFs par minute)

Mais avant d’aller plus loin, mettons-nous d’accord sur la définition d’un code smell :

« Smells are certain structures in the code that indicate violation of fundamental design principles and negatively impact design quality. » - Girish Suryanarayana (Issue du livre Refactoring for Software Design Smells : Managing Technical Debt)

D’après la définition de Girish Suryanarayana, un code smell est une violation aux fondamentaux des principes de conception. Par conséquent, ces violations auraient, à terme, un impact négatif sur la qualité d’une solution. En tant qu’aspirants artisans du code, la qualité est un sujet central sur lequel nous ne souhaiterons pas faire de concession, oh que non ! Cependant, il est intéressant de mettre en perspective la définition de G. Suryanarayana avec le point de vue de Martin Fowler.

Ce dernier explique que les smells ne sont pas toujours problématiques :

« smells don’t always indicate a problem. » - Martin Fowler (https://martinfowler.com/bliki/CodeSmell.html)

D’après Martin Fowler, une méthode qui serait longue ne serait pas forcément source de problème. Un regard plus poussé serait nécessaire pour identifier le problème sous-jacent. En effet, il explique sur son site que les codes smells sont plus un indicateur de problème, que le problème en soi.

À la lumière de ces points de vue, nous pourrions convenir qu’un code smell tendrait à indiquer une faiblesse en matière de design. Une faiblesse qui pourrait éventuellement ralentir le rythme de développement, introduire des bugs et des dysfonctionnements parasites.

On en arrive légitimement à se poser quelques questions.

Initiation au DDD

Reconnaissez-vous cette carte ? À votre avis, de quelle année date-t-elle ?

Carte Cheonhado - 17-18e siècle - Wikimedia commons

Il s’agit d’une version coréenne de la carte du monde. C’est avec cette même illustration qu’Eric J. Evans démarre son livre Domain Driven Design: Tackling Complexity in the Heart of Software. Cette modélisation valorise une Chine centrale. Elle reflète une appréciation du monde à travers le prisme coréen. Au XVIII^e siècle, la Chine était perçue comme un acteur prédominant de l’économie et de la géostratégie régionales. Cette représentation sert ainsi à décrire des rapports propres aux intérêts locaux de cette époque.

« Maps are models, and every model represents some aspect of reality or an idea that is of interest. A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail. » - Eric J. Evans

Un logiciel vient en réponse à des besoins, des problèmes rencontrés par des utilisateurs finaux en rapport avec un domaine donné. On peut caractériser un domaine comme étant le périmètre d’activités pour lequel l’utilisateur va avoir recours à un logiciel. En fin de compte, le Domain Driven Design vient proposer un jargon commun, une méthodologie et des principes de modélisation permettant de résoudre une problématique métier complexe et à interprétations plurielles.

De quoi on parle ? - Phénomène d’interprétation multiple

Mais pourquoi s’équiper d’un autre package théorique ? On a déjà assez vu de DD comme ça ! Entre le TDD, le BDD, l’ATDD ou encore de CTDD, pourquoi d’autres termes DD-suffixables (barbarisme pour identifier toute notion à laquelle on accroche le suffixe DD - Driven Design/Development.) ? Il se trouve que sans cela, il serait difficile d’évoluer et de s’épanouir au sein d’une communauté de professionnels, et ainsi d’être à même de pleinement apprécier...

Architecture propre et solide

« Introducing abstractions early, with no justification other than “we may need it in the future,” is what makes applications so complicated. » - The Software Craftsman

L’architecture a toujours été au centre de nombreux débats. Le choix d’une bonne architecture servira à la mise en place de logiciels pérennes. Une mauvaise architecture se révélera comme l’une des sources qui hanteront l’échec d’une solution applicative. Au long des dernières décennies, plusieurs experts se sont penchés sur le sujet. De nombreux principes, de multiples règles et théorèmes ont ainsi vu le jour.

Et pourtant, à ce moment précis, il n’existe pas de recette miracle en termes d’architecture. Et même dans le cas où une équipe utiliserait le bon principe d’architecture au démarrage, elle ne sera pas à l’abri, tôt ou tard, d’en observer certaines limites, voire l’obsolescence. L’évolution perpétuelle des technologies ouvre par nature la porte à de nouveaux usages techniques et à de nouvelles expériences utilisateur. Ainsi, les fondations d’une application pourront être remises en cause à tout moment.

Dans certains cas, on vous dira, « Utilise le pattern Visitor !», « Tu ne connais pas le pattern Proxy ? » ou encore « les Génériques c’est bien, on pourrait les mettre en place dans notre prochain sprint… ». Pour finir, vous échapperez de moins en moins à une discussion vous incitant à reproduire une architecture hexagonale, voir une clean architecture, telle que décrite dans le livre d’Uncle Bob. Comment agir en tant qu’aspirant craft dans une situation ou dans l’autre ? Cela vous revient, et il est bon de prendre du recul sur le contexte d’un projet et la maturité technique d’une équipe avant de plonger becs et ongles dans l’implémentation de décisions aussi sensibles sans un minimum d’argumentaire.

À ce moment, j’aime raconter l’histoire de l’aspirant craft qui, un jour, avait entrepris de se rendre à CraftsLand. Sur la route...

Gestion du Legacy

« Legacy code is simply code without tests. » - Michael Feathers

Les systèmes d’information, les bases de données, les lignes de code évoluent avec le temps. Certaines solutions applicatives vieillissent bien pendant que d’autres moins. Elles restent toutefois en vie du moment qu’elles continuent à accomplir ce pour quoi elles ont été créées : répondre aux besoins des utilisateurs.

L’évolution des systèmes s’accompagne d’une mutation de l’écosystème projet qui en fait la maintenance corrective et évolutive. Avec le temps, les équipes en charge du code de l’application changent, la connaissance et son transfert deviennent un sujet de tous les jours pour l’entreprise, pendant que le système grandit en matière de fonctionnalités et de complexité. La complexité sans tests rend tout code fragile. Et dans cette configuration, corriger un bug ou rajouter une nouvelle fonctionnalité devient un jeu périlleux qui conduit à des dommages collatéraux. 

Bonne chance !

Nombre d’experts se sont penchés ces dernières décennies sur les problématiques liées à la gestion du legacy, ce code écrit par autrui, il y a de cela quelque temps, voire des années, et dont on hérite tant bien que mal pour en devenir responsable face aux autres équipes de l’organisation et face aux utilisateurs finaux. Que ce soit Micheal C. Feathers dans son livre Working Efficiently with Legacy Code ou encore Kent Beck et Martin Fowler avec leurs ouvrages sur le refactoring du code, ils en appellent principalement à l’usage pragmatique des tests et du refactoring par incréments. Ils expriment l’utilité d’identifier et de pratiquer certaines techniques pour traiter avec efficacité et sérénité un sujet aussi sérieux et critique pour les entreprises.

En effet, les enjeux sont nombreux et en voici quelques-uns :

Synthèse et exercices