Qu’est-ce que la complexité ?

Récemment, j'ai fini de lire « Une philosophie de la conception logicielle » et dans le deuxième chapitre, il explore le sujet de la complexité logicielle. 

Le livre "A Philosophy of Software Design" définit la complexité de manière pratique :

"La complexité est tout ce qui concerne la structure d'un système logiciel qui le rend difficile à comprendre et à modifier."

En d'autres termes, la complexité peut prendre plusieurs formes et n'a pas nécessairement quelque chose à voir avec les performances, votre code peut être performant tout en restant complexe

J'aimerais partager quelques définitions et idées clés du livre dans cet article. Mais d’abord, imaginons une situation courante que vous avez probablement déjà vécue…

Une courte histoire d'horreur

Plongeons dans une histoire d'horreur que beaucoup d'entre vous ont probablement vécue ou vivront.

1. Cela a commencé avec une simple application de gestion de tâches CRUD. Le code était propre, modulaire et facile à maintenir. L'équipe de développement était satisfaite et le système a parfaitement fonctionné pour les premiers clients.

2. Les problèmes ont commencé lorsque l'équipe commerciale a vendu le système à une grande entreprise, affirmant qu'il disposait d'une intégration de calendrier, de notifications par e-mail et d'un incroyable générateur de rapports. Une fois la vente finalisée, ces fonctionnalités ont dû être mises en œuvre rapidement.

3. Intégration du calendrier : L'équipe a dû intégrer Google Calendar et Outlook. Différents développeurs ont mis en œuvre les solutions, ce qui a donné lieu à des approches incohérentes.

4. Notifications par e-mail : Les notifications par e-mail ont ensuite été ajoutées. Un développeur a utilisé une bibliothèque spécifique, tandis qu'un autre a créé une solution personnalisée. Les approches mixtes ont rendu le code déroutant.

5. Générateur de rapports : Pour le générateur de rapports, les développeurs ont utilisé diverses technologies : fichiers PDF, exportations Excel et tableaux de bord interactifs. L'absence d'une approche unifiée a fait de la maintenance un cauchemar.

6. Complexité croissante : Chaque fonctionnalité a été développée de manière isolée et rapidement, ce qui entraîne des dépendances entre les fonctionnalités. Les développeurs ont commencé à créer des « solutions rapides » pour que tout fonctionne, augmentant ainsi la complexité et le couplage du système.

Le développement de logiciels ne se fait pas en vase clos ; divers facteurs internes et externes l’influencent. Nous avons tous été, ou serons, dans une situation comme celle-ci.

Le début de la fin

Puis les problèmes ont commencé :

1. Les modifications apportées à une partie du système ont affecté d'autres parties de manière inattendue.
2. De petits changements ont nécessité des modifications dans de nombreux autres fichiers, rendant les estimations difficiles.
3. Mois après mois, le code est devenu plus difficile à comprendre, souvent corrigé par essais et erreurs.
4. La productivité a diminué et tout le monde redoutait les tâches de maintenance.
5. L'appel inévitable à "Nous devons refactoriser."
6. Certaines tâches ne pouvaient être gérées que par des développeurs spécifiques (classique)
7. Au fil du temps, ce logiciel autrefois magnifiquement écrit et bien documenté est devenu un désastre.

Nommer les symptômes

Il est clair que nous avons désormais un système complexe.

Maintenant, « disséquons » cette complexité pour faciliter son identification et son atténuation.

Eh bien, « atténuer » signifie :

"Pour rendre moins grave, grave ou douloureux ; pour soulager."

Je pense que la complexité est souvent inhérente au code. Certaines choses sont complexes par nature. Votre rôle en tant que développeur n'est pas seulement de créer du code que l'ordinateur peut exécuter efficacement, mais également de créer du code avec lequel les futurs développeurs (y compris votre futur moi) pourront travailler.

« Le contrôle de la complexité est l'essence même de la programmation informatique. »

—Brian Kernighan

L'auteur du livre mentionné déclare que la complexité se manifeste généralement de trois manières, que nous explorerons ici.

Modifier l'amplification

L'amplification du changement se produit lorsqu'un changement apparemment simple nécessite des modifications à de nombreux endroits différents.

Par exemple, si le Product Owner demande un champ « priorité » ou « date d'achèvement » et que vos entités sont étroitement couplées, combien de modifications devrez-vous apporter ?

Charge cognitive

La charge cognitive fait référence à la quantité de connaissances et au temps dont un développeur a besoin pour accomplir une tâche.

Alors imaginez ce scénario : un nouveau développeur a rejoint l'équipe, il a été chargé de corriger un bug dans le générateur de rapports. Pour accomplir cette tâche, le développeur devait :

• Comprendre les différentes intégrations de calendrier (Google et Outlook).
• Découvrez les différentes approches en matière de notifications par e-mail.
• Naviguez dans le code fragmenté du générateur de rapports, traitant des PDF, Excel et des tableaux de bord.
• Intégrez ces diverses technologies et styles pour rechercher et corriger le bug.

Il s'agit du scénario classique « impossible à estimer », dans lequel la tâche pourrait prendre un ou huit points : mieux vaut lancer un D20 et répondre en conséquence.

Inconnus Inconnus

Les inconnus inconnus, c'est quand vous ne savez pas ce que vous ne savez pas.

C'est la pire manifestation de complexité, car vous pourriez modifier des choses que vous ne devriez pas, ce qui provoquerait la rupture de tout.

Exemple : Un développeur a modifié le code d'envoi d'e-mail pour ajouter une nouvelle notification, ignorant que cela affecterait le générateur de rapports, qui dépendait de cette fonction. Cela a causé des problèmes importants aux clients, illustrant la pire forme de complexité émergente.

Causes de la complexité

Après avoir vu l'histoire d'horreur et les trois principaux symptômes, regardons ce qui cause la complexité.

1. Dépendances

Les dépendances sont essentielles dans les logiciels et ne peuvent pas être complètement éliminées. Ils permettent aux différentes parties du système d’interagir et de fonctionner ensemble. Cependant, les dépendances, lorsqu'elles ne sont pas gérées correctement, peuvent augmenter considérablement la complexité.

Définition:

Une dépendance existe lorsque le code ne peut pas être compris ou modifié de manière isolée, nécessitant la prise en compte ou la modification du code associé.

Types de dépendances :

• Direct : Le module A s'appuie directement sur le module B.
• Transitif : Le module A s'appuie sur le module B, qui s'appuie sur le module C.
• Cyclique : Les modules A, B et C sont interdépendants de manière circulaire.

2. Obscurité

L'obscurité se produit lorsque des informations importantes ne sont pas évidentes. Cela peut rendre la base de code difficile à comprendre, entraînant une charge cognitive accrue et le risque d'inconnues.

Définition:

L'obscurité se produit lorsque des informations importantes ne sont pas évidentes.

Exemples d'obscurité :

• Mauvais nom : Variables et fonctions dont les noms ne sont pas clairs.
• Effets secondaires cachés : Méthodes qui effectuent des actions inattendues.
• État global : Surutilisation des variables globales.
• Héritage profond : Comportement réparti sur de nombreux niveaux dans les hiérarchies de classes.

N'oubliez pas : la complexité est incrémentielle

• La complexité est rarement causée par une seule « erreur » ou une mauvaise décision.
• La complexité s'accumule « lentement » à cause des mauvaises décisions et des dépendances au fil du temps.

Parce que c'est progressif, il est facile de penser : « juste pour une fois, cela n'aura pas d'importance ». Mais une fois accumulés, réparer une ou deux dépendances à lui seul ne fera pas beaucoup de différence.

« Tout est un compromis en matière d'ingénierie logicielle. »
— Je ne me souviens pas de l'auteur

Conclusion

Je pourrais écrire beaucoup de règles, de stratégies et de cadres que vous avez probablement déjà vus sur Internet sur la façon d'éviter la complexité : SOLID, Design Patterns, YAGNI, KISS, etc.

Cependant, vous pouvez les unifier tous en un seul principe directeur (comme mentionné dans « Le programmeur pragmatique. ») : « Ce que j'implémente est-il facile à modifier ? » Si la réponse est non, alors vous augmentez probablement la complexité.

S'assurer que votre code est facile à modifier simplifie la maintenance, réduit la charge cognitive des développeurs et rend le système plus adaptable et moins sujet aux erreurs.

Merci!