Quand on parle de charge cognitive, on pense surtout à la charge mentale engendrée par la gestion du foyer et les tâches ménagères, qui touche malheureusement encore trop souvent les femmes (on est en 2019, faites un effort, messieurs). En dehors de l’aspect sociologique, ce principe s’applique dans le domaine de la résolution de problèmes, au cœur du métier de développeur. Outre la charge intrinsèque à la complexité de la tâche à effectuer, il demeure une charge dite extrinsèque, qui découle du contexte, de la manière dont est présentée l’information.

C’est ce deuxième type de charge qui nous intéresse et que nous allons essayer de réduire au minimum à l’aide de plusieurs méthodes.

Le métier de développeur consiste en grande majorité à de la prise d’informations. Nous passons des heures à lire et à nous imprégner de centaines de lignes de code pour écrire des fonctions qui n’en font parfois pas plus d’une douzaine.

Un développeur en train “d’écrire” du code

La théorie de la charge cognitive dit que la mémoire de travail (ou mémoire à court terme) ne peut traiter que trois à quatre données en parallèle. Autrement dit, il est tout autant dans notre intérêt de nous débarrasser de toute distraction ou élément parasite que de produire du code de manière aussi élégante et consistante que possible.

Confort visuel

Nous passons 80 % de notre temps de travail à scruter un écran, autant rendre l’expérience confortable. La font, la taille et l’espacement des caractères, la palette de couleurs sont autant de variables qui ont un impact majeur sur la façon dont est perçue l’information, et pas seulement sur la fatigue oculaire ou les sensibilités esthétiques de chacun.

Prenons aussi en considération la manière d’agencer l’information :

Il existe des standards de code par dizaines, rien qu’en PHP. Il serait inutile d’en défendre un plutôt qu’un autre, l’idée ici est de faire comprendre l’importance d’en adopter un et de s’y tenir. Les développeurs ne lisent pas en intégralité des pages de code, contrairement aux pages d’un livre. Nous les parcourons rapidement du regard à la recherche de l’information qui nous intéresse.

D’où l’intérêt d’uniformiser au maximum les aspects déjà répétitifs pour donner des repères visuels : indentations et retours à la ligne ont un rôle primordial dans la lecture rapide du code. Un développeur chevronné aura parfois l’œil plus attiré par une accolade mal placée dans une fonction que par son rôle de fond.

Accolade mal placée, allégorie

Réutilisabilité et pérennité

Tous les développeurs ont un jour froncé les sourcils devant un morceau de code sans avoir aucun souvenir de ce qui leur passait par la tête lorsqu’ils l’ont écrit quelques semaines auparavant.

La syntaxe et la lisibilité ne suffisent parfois pas à s’y retrouver rapidement quand il s’agit de reprendre du code qui ne nous est pas familier. Pour maximiser la productivité, il faut être capable d’ajouter une fonctionnalité à un programme déjà existant sans devoir fouiller dans plusieurs fichiers dispersés dans les sources du projet pour y comprendre quelque chose.

La réponse évidente à cette problématique est la mise en place d’une documentation. La question de la place des commentaires dans le développement est toujours délicate et, n’en déplaise à certains, un code idéalement écrit devrait pouvoir s’en passer.

Malheureusement, nous vivons dans un monde imparfait et nous aurons toujours besoin de ces petites lignes de texte gris pour nous faire comprendre ces méthodes un peu cryptiques dont le rôle n’est pas immédiatement évident. Dans l’optique de s’affranchir de la dette visuelle que les commentaires représentent (et donc de la charge cognitive qui en découle), nous pouvons nous intéresser à la verbosité du code en lui-même.

Une méthode devrait avoir un rôle unique et devrait porter un nom qui lui correspond exactement. À proscrire donc les noms de variable et de fonction trop génériques tels que “get”, “item”, var1”, etc.

Prenons les deux exemples suivants :

Si la première notation est plus concise, elle présente plusieurs problèmes. La définition de la méthode “get” est ambiguë, nous n’avons à ce stade aucune idée de ce qu’il est possible ou pas de faire avec. Nous sommes donc contraints d’aller regarder la définition de la classe Pokedex pour en avoir le cœur net. À l’inverse, la seconde notation permet de comprendre immédiatement le rôle de la méthode “getPokemonByType” et de la variable “$waterPokemon” sans nécessiter l’ajout de commentaires.

C’est une gymnastique mentale qui peut paraître contre-productive, mais elle offre un gain de temps considérable à moyen et long terme.

Environnement et outils

De nombreux autres éléments sont facteurs d’augmentation ou de diminution de charge cognitive. L’odeur rassurante du café frais, un IDE dont on connaît les raccourcis littéralement sur le bout des doigts, un espace de travail confortable avec une luminosité suffisante sont vecteurs d’apaisement et facilitent donc la concentration. En revanche, les notifications Slack, un collègue trop agité, un réseau wifi instable ou n’importe quel paramètre environnemental peuvent générer une distraction qui prendra la place d’une de ces trois ou quatre données que notre cerveau est capable de traiter en même temps.

*Ding*

En bref

Un environnement affranchi de toute distraction et une méthode bien appliquée permettent à l’esprit de travailler plus efficacement à la résolution de problèmes au même titre qu’il aide à se débarrasser de l’angoisse de la page blanche. Cependant, la recherche de l’environnement de travail parfait ne doit pas non plus être un frein à la productivité. Comme pour tout le reste, il faut savoir se servir de méthodes éprouvées et avant tout oser se mettre au travail. L’Action engendre la Réflexion.

Sources :

Charge Cognitive : emmaclit.com/2017/05/09/repartition-des-taches-hommes-femmes/
stitcher.io/blog/a-programmers-cognitive-load
wikipedia.org/wiki/Charge_cognitive#Charge_extrins%C3%A8que
ocramius.github.io/blog/eliminating-visual-debt/
wikipedia.org/wiki/Procrastination