Certaines complexités sont plus utiles que d’autres

Nous l’avons vu, la complexité est rarement source de bonne nouvelle dans un code source. Mais saviez-vous qu’il existait plusieurs types de complexités ? Et que certaines complexités sont indispensables ?

Savoir classifier la complexité nous permet de mieux appréhender les situations que nous rencontrons au quotidien. C’est un outil particulièrement utile pour savoir dans quelle direction concentrer nos efforts afin de garder la complexité sous contrôle.

Une complexité en trois parties

Candidement, nous avons tendance à penser la complexité d’un logiciel comme un tout.

Mais la réalité nous montre que nous pouvons découper cette complexité en trois. Et vous allez voir, cela va nous aider à mieux appréhender les problèmes que nous rencontrons.

Cette classification est tirée de « there is no silver bullet » une nouvelle de Frederick P. Brooks, l’auteur du génial « The Mythical Man Month ».

Diagramme de complexité accidentelle, obligatoire et essentielle du logiciel
La complexité d'un logiciel peut être catégorisée en trois parties

Le problème que l’on cherche à résoudre : la complexité essentielle

Une première source de complexité est directement liée au problème métier que l’on cherche à résoudre. Vous imaginez bien qu’un système de livraison multimodale n’a pas la même complexité qu’un blog personnel en ligne. Les complexités essentielles de ces deux projets sont différentes.

Ce qui est nécessaire : la complexité obligatoire

La complexité obligatoire est la complexité qui est nécessaire pour que le logiciel rende un service. Par exemple si vous codez une API de paiement pour une plateforme web, il vous faudra un serveur HTTP.

Ce serveur HTTP ne fait pas partie de la complexité essentielle (qui est liée au système de paiement), mais il est obligatoire pour que votre application soit utile.

Et enfin, tout ce qui reste : la complexité accidentelle

Ce qui reste de complexité n’est pas lié au problème métier et n’est pas nécessaire à celui-ci. C’est donc qualifié de complexité accidentelle, c’est une complexité qui ne devrait théoriquement pas exister.

Cette complexité peut être liée à des choix malheureux dans la conception du code, dans la sélection des outils, mais aussi le fait de l’entropie du logiciel (nous en reparlerons dans un autre article).

Tous les logiciels ne naissent pas égaux

Cette première distinction en tête, nous pouvons déjà imaginer que tous les logiciels ne vont pas avoir la même répartition entre ces trois complexités.

Au-delà de la complexité essentielle, directement liée au problème que l’on cherche à résoudre. Les contraintes techniques et réglementaires qui pèsent sur un projet peuvent modifier radicalement la complexité obligatoire de celui-ci.

À même complexité essentielle, deux programmes peuvent avoir une complexité obligatoire très différente.

Par exemple, chez LGO, nous travaillons sur des systèmes pour la finance de marché. Aussi, nous avons une double contrainte : haute performance et haute disponibilité. Mécaniquement, ces deux contraintes augmentent fortement la complexité obligatoire du code source de l’application.

Faites attention à la répartition de la complexité dans votre code

Cette catégorisation nous permet aussi de mieux évaluer les risques en termes de maintenabilité future d’un logiciel. À complexité égale deux codes sources peuvent en réalité cacher des réalités très différentes.

Attention à la complexité accidentelle, celle-ci augmente la complexité de votre logiciel pour rien. 

En effet, un code avec une complexité accidentelle conséquente va avoir plus de problèmes de maintenance. En plus du fait qu'il entraine une charge cognitive plus importante.

Ceci conclut ce premier article, dédié aux types de complexité, dans les prochains articles de la série nous verrons les éléments stratégiques permettant de la garder sous contrôle. Pour être sûr de les recevoir, abonnez-vous à la newsletter !


Si vous l'avez apprécié, n'hésitez pas à partager cet article sur twitter, Linkedin, ou sur Slack.

Merci à @SebastienChemin & Olga Cojocariu qui m'ont apporté leur aide pour l’écriture de cet article

Arnaud LEMAIRE

DDD lover & Code designer, XP practitioner. Deputy CTO @ lgo.group

Super ! Vous vous êtes inscrit avec succès.
Super ! Effectuez le paiement pour obtenir l'accès complet.
Bon retour parmi nous ! Vous vous êtes connecté avec succès.
Parfait ! Votre compte est entièrement activé, vous avez désormais accès à tout le contenu.