L’esthétique de la destruction logicielle — comment lutter contre l’incertitude

• Beaucoup de choses sont incertaines dans le logiciel.
• Pourquoi cette incertitude ?
  • La raison principale est l’existence de la complexité métier.
  • À cause de cette complexité, la situation évolue en permanence, et les prévisions des développeurs ont donc de fortes chances d’être erronées.
  • Des constructions élaborées avec soin s’effondrent et se transforment telles quelles en dette technique.
  • Une raison plus mineure est le manque de connaissances et d’expérience.
  • Sans connaissances ni expérience, les développeurs peuvent eux-mêmes créer de la dette technique.
  • La complexité métier est un facteur externe que les développeurs ne peuvent pas contrôler, tandis que les connaissances et l’expérience sont des facteurs internes qu’ils peuvent contrôler.
• Trois voies s’offrent aux développeurs.
  • La voie pessimiste, qui considère qu’il est inutile de lutter contre la complexité
    • On finit par dire des choses comme « de toute façon, ça changera, alors faisons-le comme ça » ou « la technique ne sert à rien ».
    • C’est une voie confortable et rassurante, si bien qu’on peut la choisir sans même s’en rendre compte.
  • La voie qui ignore la complexité et ne pense qu’à un idéal imaginaire
    • On croit qu’une seule technologie, celle qu’on juge idéale, peut tout résoudre.
    • On en vient à adopter une pensée rigide et uniforme.
    • C’est une voie dans laquelle les développeurs tombent facilement, mais dont il est difficile de sortir.
  • La voie qui accepte la complexité et l’affronte
    • Même en acceptant qu’on ne peut pas atteindre la perfection, on continue à chercher une meilleure voie.
    • C’est un chemin difficile, qui demande de tenir bon.
  • Le développement logiciel n’a cessé de lutter contre la complexité.
    • Architecture, méthodologies, agile, etc.
    • Que verra-t-on apparaître ensuite ?
• Développement orienté destruction
  • En regardant la réalité, il est facile de sombrer dans l’idée pessimiste que, de toute façon, tout sera supprimé un jour.
  • Parce qu’effacer soi-même du code écrit avec soin, en ayant le sentiment qu’il s’agit d’un échec, est extrêmement douloureux.
  • Et si, en renversant la perspective, on cherchait plutôt à le rendre facile à supprimer ?
• La destruction est-elle une bonne chose ?
  • Sans destruction, rien de nouveau ne peut naître.
  • Dans le logiciel, on peut observer deux grandes formes de destruction : le pivot et le refactoring.
  • Le pivot permet à l’organisation et au produit de choisir une meilleure direction.
  • Le refactoring est indispensable pour prolonger la durée de vie du logiciel.
• Alors, qu’est-ce que le développement orienté destruction ?
  • Une méthodologie qui consiste à accepter que le code sera détruit un jour, et à développer en gardant cela comme orientation.
  • Elle vise trois grands principes.
    • S’il y a de l’incertitude, la réduire autant que possible.
    • Si plusieurs approches sont possibles, choisir celle qui est la plus facile à détruire.
    • Ne conserver que ce qui est nécessaire. Par conséquent, supprimer tout ce qui ne l’est pas.
  • Analyse -> séparation des frontières -> implémentation du code -> suppression de la complexité
  • L’essentiel est de réduire l’incertitude liée aux facteurs internes et de se préparer aux destructions causées par les facteurs externes, inévitables.
• Séparation des frontières
  • L’incertitude est un taux de changement, et il est possible de s’appuyer dessus pour séparer.
  • Les développeurs doivent se préparer aux facteurs externes tout en réduisant autant que possible le taux de changement dû aux facteurs internes.
  • Comme le taux de changement de chaque facteur peut varier d’une organisation à l’autre, il est impossible de l’exprimer avec une valeur fixe -> il faut donc le mesurer de manière heuristique.
    • ex) estimation en story points
  • Il faut déterminer le niveau d’abstraction en fonction du critère de séparation choisi.
• Destructibilité
  • Lors de l’implémentation, il faut choisir l’option la plus facile à détruire, conformément aux grands principes.
  • On peut évaluer la destructibilité en prenant en compte l’indépendance, l’intelligibilité et la contrôlabilité.
    • L’indépendance se juge selon le degré de couplage et de cohésion, ainsi que selon le respect du principe de responsabilité unique.
    • L’intelligibilité correspond au degré auquel un développeur peut lire et comprendre le code.
    • La contrôlabilité consiste à déterminer si l’on se trouve dans un périmètre que le développeur peut contrôler.
• Suppression de la complexité
  • Il faut vérifier s’il existe des éléments inutiles et les supprimer. En d’autres termes, au final, seule la partie nécessaire doit rester dans la base de code.
  • S’il est difficile de travailler dessus à cause d’échéances ou d’autres contraintes, le simple fait de le consigner suffit et cela ne pose pas de problème.
    • Parce que les facteurs internes sont contrôlables.
  • L’essentiel est de préserver au maximum la simplicité afin d’être prêt pour la destruction.
• Les techniques de destruction du code
  • Il existe divers principes et méthodes pour bien supprimer du code.
  • Découper en étapes (pattern de refactoring)
  • Préserver la transparence référentielle
  • Respecter le principe de responsabilité unique
  • Respecter le principe de séparation des interfaces
  • Pattern du figuier étrangleur
  • Spécialisation des méthodes
  • Écriture de code dupliqué
  • Journalisation du taux de changement

[annonymous1]

Je n’adhère pas vraiment à l’idée que la dette de code viendrait d’un manque de connaissances et d’expérience chez les développeurs.

-> Il peut tout simplement manquer de temps pour implémenter les exigences, et dans un contexte de collaboration, on peut aussi accepter un peu de dette technique pour rester en harmonie avec les autres ; je pense que les situations sont diverses.

Je ne suis pas non plus convaincu par l’idée de considérer les connaissances et l’expérience comme des facteurs internes que les développeurs peuvent contrôler.

-> Le business est complexe, on ne peut pas prévoir toutes les situations qui vont se présenter, et on ne peut pas non plus étudier tous les cas de figure au fur et à mesure. Même si on se forme une fois confronté à une situation, la fois suivante un problème totalement nouveau peut surgir, rendant ces connaissances inutiles.

[kciter1]

Bonjour. Merci pour votre avis.
Je pense qu’on ne peut voir l’essence des choses qu’en examinant les cas extrêmes. Dans cette perspective, je pensais que si l’on maîtrisait parfaitement les « connaissances et l’expérience », on pourrait produire dans les délais du code qui ne soit pas de la dette technique.

Le manque de temps peut se diviser en deux cas. Le premier est le cas où, littéralement, le temps nécessaire à l’implémentation manque. Dans ce cas, indépendamment des connaissances et de l’expérience, le temps physique pour écrire le code vient à manquer. Dès lors, les conditions ne permettent tout simplement pas d’atteindre l’objectif. Le second est le cas où l’on manque de temps pour déterminer ce qui est bon. Dans ce cas, faute de temps pour apprendre comment implémenter les choses ou pour trouver une meilleure solution, on termine le travail en écrivant le code uniquement avec les connaissances dont on dispose à cet instant. En achevant ainsi la tâche, on sait bien que « quelque chose ne va pas », mais on ne sait pas exactement comment le corriger. Si l’on disposait d’un savoir précis et de la confiance acquise par l’expérience correspondante, ce genre de problème ne se produirait pas.

Je pense que le manque de temps évoqué plus haut vient appuyer mon point de vue. Bien sûr, en pratique, c’est un problème extrêmement difficile. Je n’ai fait qu’énoncer un idéal. Il est rare de disposer parfaitement des connaissances et de l’expérience, et comme vous l’avez dit, il existe clairement des cas où l’on accepte délibérément cela pour l’organisation. Cela peut sembler injuste, mais en regardant ce problème « de manière extrême », j’ai pensé qu’il survenait parce que les connaissances et l’expérience faisaient défaut.

Concernant le second facteur interne que vous avez mentionné, c’est simple. « Le business est complexe, donc on ne peut pas prévoir quelle situation va surgir… » : dans mon texte, cela correspond à ce que j’appelle la « complexité du business ». Autrement dit, c’est un problème causé par des facteurs externes. Comme il s’agit de facteurs externes, le développeur ne peut pas les contrôler et ressent donc de la peur. Là encore, si l’on adopte une vision extrême et que l’on suppose qu’il n’existe aucune complexité business, il ne reste alors que le code écrit par le développeur. Dans ce cas, il ne subsiste plus que le problème des « connaissances et de l’expérience », qui peut être contrôlé en interne.

Bien sûr, le texte que j’ai écrit n’est lui aussi que mon opinion. Il peut tout à fait exister des contre-exemples. Je pense que l’échange d’opinions est une occasion d’avancer vers une meilleure voie. J’espère donc avoir encore beaucoup de retours de votre part à l’avenir. Merci.

[annonymous1]

Merci pour votre réponse bienveillante.

[winterjung]

J’ai beaucoup apprécié la lecture de cet article. J’ai l’impression que, selon le stade de l’organisation, ce qui relève d’une optimisation prématurée ou d’un surdimensionnement de l’ingénierie peut aussi varier. Le point difficile, c’est qu’il s’agit de code qu’il faudra de toute façon réécrire un jour, tout en ne sachant même pas si ce moment viendra réellement. De mon côté, il m’arrive aussi de me baser sur la question suivante pour trancher : si le service xxx ou une fonctionnalité venait à disparaître, où serait l’endroit approprié pour le code yyy et les données ? Je serais curieux de connaître les méthodes des autres.

[savvykang]

J’ai tendance à réfléchir au fait que non seulement le code, mais aussi les données ou les schémas, peuvent disparaître ou être modifiés.

1. Je réfléchis à laquelle des trois catégories — schéma de base de données, protocole (comme une API REST) et fonctionnalités — correspond le code. Les schémas et les protocoles se propagent inévitablement dans le code interne de l’entreprise ou à l’extérieur ; plus tard, on ne peut donc pas les modifier seul en quelques jours, et cela nécessite de la collaboration. J’y consacre donc un peu plus de temps dès la phase de conception.
2. Je réfléchis au cycle de vie et à la volatilité des données que le code manipule. Cela inclut probablement aussi la situation que winterjung évoque, lorsque le service disparaît. La classification en grand livre, transactions et tables d’historique, dont on parle en OLTP, peut aussi être une bonne manière de commencer à réfléchir à ces questions.

[kciter1]

Je voulais aussi inclure une partie sur les données, mais j’avais du mal à clarifier mes idées. Comme c’est un point critique, il est difficile d’y toucher à la légère, et je restais prudent car on peut facilement tomber dans l’enfer de la migration.

Comme vous l’avez dit, la phase de conception initiale semble vraiment très importante. Le point clé sera sans doute de faire en sorte d’accumuler les données brutes (RAW) aussi proprement que possible. Sinon, une architecture d’event sourcing pourrait être avantageuse du point de vue de la suppression. Bien sûr, je ne l’ai jamais vraiment utilisée correctement, donc je ne sais pas si ce sera réellement pertinent.