La complexité, une histoire de charge cognitive

C’est quoi cette « charge cognitive » ?

Avez-vous déjà connu cette sensation d’être noyé par la quantité d’éléments que vous deviez garder en tête pendant le développement d’une fonctionnalité ?
Ce symptôme, très fréquent, est souvent le signe d’un code source trop complexe. Vous êtes alors en situation de « surcharge cognitive ».

La charge cognitive est caractérisée par le nombre d’éléments nécessaires à la résolution d’un problème. Plus particulièrement, ce sont les éléments que nous devons garder dans la mémoire de travail. Ce concept de « charge cognitive » a été initialement développée par J.Sweller dans son article Cognitive Load During Problem Solving.

Plus vous devez conserver d’informations en tête pour travailler, plus votre charge cognitive augmente. La « surcharge cognitive » arrive donc quand nous n’avons plus les moyens de retenir le contexte de travail.

Alors comment éviter cette situation, et comment éviter de la faire subir à vos collègues ?

Quand la taille ne compte pas

La première idée est de diminuer la taille du code source pour corriger ce problème. Et effectivement, c’est une première bonne étape. Malheureusement, notre mémoire de travail est vraiment très limitée. Elle ne peut contenir qu’entre 5 et 9 éléments. Même le plus simple des programmes ne peut pas y entrer en totalité.

Ainsi, l’objectif est de minimiser le nombre d’éléments nécessaires pour comprendre et intervenir sur un code source. Et nous retrouvons là des problématiques classiques d’ingénierie logicielle :

• Limiter au maximum le nombre d’éléments dans un contexte donné. Avoir peu de lignes de code par méthode, peu de paramètres par méthode, peu de méthode par classe, etc. Effectivement, Il n’est pas très agréable de travailler avec une méthode de 500 lignes qui prend 14 paramètres et qui mute 23 champs.
• Découpler son code source. Cela permet de limiter le contexte nécessaire à sa compréhension. En effet, le découplage permet d’éviter le syndrome du code spaghetti, où dès que vous essayez de comprendre ce qui se passe dans le code vous vous retrouvez avec 63 fichiers ouverts dans votre IDE. Le manque de découplage est la première cause d'une charge cognitive trop importante (et ça ne veut pas dire faire des microservices).

C’est pourquoi un logiciel avec peu de lignes de code peut avoir une charge cognitive plus conséquente qu’un code source avec beaucoup plus de lignes de codes mais qui a bénéficié d’un travail de conception soignée.

Nous ne sommes pas égaux face à la charge cognitive

Si le nombre d’éléments que nous pouvons garder en tête est très limité, la taille de ces éléments ne semble pas avoir une grosse influence sur la charge cognitive.

Et c’est là où l’expérience va jouer un rôle important. En effet en tant que débutant, nous sommes souvent amenés à analyser le code source instruction par instruction. Nous n’avons pas l’expérience pour reconnaitre certaines structures, ce qui entraine la nécessité de garder en tête plus de détail.

Avec l’expérience, il devient plus facile de lire un code source et de le comprendre car intuitivement on abstrait les instructions que nous avons sous les yeux. Cette expérience à bien évidemment plusieurs dimensions : expérience professionnelle, expérience avec le code source que nous manipulons et expérience avec le domaine métier dans lequel nous évoluons.

L’abstraction à la rescousse

Le fait que la taille des éléments n’influence pas la charge cognitive nous permet d’aller vers une autre solution : l’utilisation d’abstractions. C’est l’intérêt de manipuler une API de haut niveau pour interagir avec des fichiers. Au lieu de devoir gérer l’ensemble du cycle de vie depuis la récupération jusqu’à l’écriture des données sur le système de fichier.

Une bonne abstraction, en éliminant le besoin de connaitre les détails d’implémentation, est un outil particulièrement puissant pour diminuer la charge cognitive. Attention à ne pas créer des abstractions inutiles, ou d'abstraire trop tôt certains concepts : l’over-ingénierie n’est jamais très loin. Et vous vous retrouvez avec la situation inverse de celle que vous espériez.

Si vous avez apprécié l’article

• N'hésitez pas à partager l’article sur twitter, Linkedin, ou sur le Slack de votre entreprise afin de le faire découvrir à des collègues, amis, ou simples connaissances qui pourraient être intéressés.
• Pour être tenu informé de la sortie des prochains articles, présentations, épisodes de podcast ou autres contenus, abonnez-vous à la newsletter grâce au formulaire juste en dessous.

Merci à @davidnotset et @SebastienChemin qui m'ont apporté leur aide pour l’écriture de cet article