GRATUIT

Vos offres d'emploi informatique

Développeurs, chefs de projets, ingénieurs, informaticiens
Postez gratuitement vos offres d'emploi ici visibles par 4 000 000 de visiteurs uniques par mois

emploi.developpez.com

Pourquoi notre code nous est-il incompréhensible ?
Un développeur se penche sur la question et identifie six problèmes

Le , par Amine Horseman, Expert éminent sénior
Tous les développeurs se sont posé un jour cette question : « pourquoi je n’arrive pas à comprendre ce bout de code ? Pourtant, c’est moi qui l’avais écrit quelques mois auparavant ! ». Le pire, c’est que parfois même en lisant les commentaires on ne comprend pas, et ça arrive si souvent qu’on se demanderait dans ces cas-là si notre intelligence s’est dégradée ou si au moment d’écrire ce code nous étions possédés par une entité intellectuelle supérieure.

Stephen Young, un développeur, designer et blogueur, a écrit récemment sur ce sujet qu’on devrait apprendre à éparpiller les miettes de pain derrière nous lorsqu’on écrit un code source pour pouvoir retrouver notre chemin lorsqu’on y revient. Oui, mais comment ?

Selon lui, il existerait 6 problèmes qui font que notre programme -si clair et élégant- ressemblera à du charabia lorsqu’on le relira quelques mois plus tard :
  1. Les modèles mentaux trop complexes : un programme est une solution à un problème du monde réel, lorsqu’on veut trouver cette solution on doit d’abord former un modèle du problème, puis un modèle de la solution (que Stephen Young appelle modèle sémantique) avant de passer au code. Il faudra donc veiller à ne pas sauter directement du problème à la solution sans former de modèles. Aussi, il faudra veiller à simplifier ces modèles autant que possible, car « les problèmes que nous tentons de résoudre sont suffisamment complexes. On ne doit pas ajouter à cela plus de complexité ».
  2. La mauvaise traduction du modèle mental : cette traduction « syntaxique » vise à transformer le modèle sémantique en code source. Le problème est qu’il est facile de traduire ce code lorsque le modèle sémantique est fraîchement cartographié dans notre tête, mais lorsqu’on y revient plus tard, ceci n’est pas aussi évident.
    Pour éviter les problèmes syntaxiques, il faudra veiller à bien choisir les noms des variables, fonctions et arguments pour qu’on puisse facilement comprendre leurs rôles. Aussi il faudra veiller que les noms des modules et classes soient autant que possible proches du modèle sémantique. De plus, il faudra que chaque classe ait un seul but : « je finis souvent par réécrire une classe parce que j’ai du mal à lui donner un nom assez court qui décrit tout ce qu'elle fait », assure Young.
    Quant aux commentaires, ils sont utiles si on n’en abuse pas, ils doivent décrire pourquoi vous avez eu à faire quelque chose et non pas comment vous l’avez fait.
  3. Pas assez de regroupement : lorsqu’on programme, on remarque qu’on a souvent besoin de répéter un nombre de choses plusieurs fois, c’est pour ça qu’il existe maintenant plusieurs Design Pattern, des fonctions standard et des bibliothèques qui sont très utiles dans le sens où « on n’a plus besoin de penser à la façon dont le code fait quelque chose, mais plutôt se concentrer sur ce qu'il fait ».
  4. Utilisation obscure de vos bouts de code : « lorsque vous revenez plus tard à votre code source, il est souvent très difficile de reconstituer toutes les utilisations prévues de vos classes et méthodes. Généralement, ceci est dû aux différents usages qui sont dispersés dans tout le reste de votre programme », écrit Young. Une des solutions à ce problème, selon lui, est de disposer d’un ensemble complet de cas de tests qui permettent d’avoir une image complète du code et de comment l’utiliser.
  5. Pas de chemin clair entre les différents modèles : ce chemin qui relie l’objectif de votre programme, au modèle sémantique puis au modèle syntaxique (code) doit être aussi simple que possible. « Parfois, il est préférable de choisir une structure de classe particulière ou un algorithme non pas pour son élégance, mais pour sa capacité à relier les différents modèles d’une façon claire et naturelle ».
  6. Inventer des algorithmes : « dans presque tous les cas, il existe des algorithmes qui peuvent être mis ensemble pour résoudre votre problème ». Programmer consiste donc à choisir des algorithmes existants dans la bonne combinaison pour résoudre un problème. Selon lui, « si vous inventez de nouveaux algorithmes, c’est soit que vous ne connaissez pas le bon algorithme à employer, soit vous travaillez sur une thèse de doctorat ».

Pour conclure, Young conseille de fournir autant d'indices que possible afin de permettre à quiconque regardant votre code de recréer le même modèle sémantique que vous aviez à l'origine dans l'esprit. « Cela paraît simple, mais en réalité c’est très difficile de faire bien ».

Source : Medium

Et vous ?

Êtes-vous d’accord avec Stephen Young sur ces six points ?

Quel problème aimeriez-vous ajouter/modifier ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Shepard Shepard - Membre éclairé https://www.developpez.com
le 03/12/2014 à 23:15
Quel soulagement d'actuellement travailler sur ma thèse de doctorat !
Avatar de Washmid Washmid - Membre actif https://www.developpez.com
le 04/12/2014 à 0:08
Ca résume la philosophie de la programmation objet

Les modèles mentaux trop complexes : la programmation objet permet de réduire la complexité unitaire de chaque "modèle" en limitant les dépendances (par opposition au modulaire)

La mauvaise traduction du modèle mental : le principe de la moindre surprise du Ruby On Rails est un très bon exemple (j'ai plus le terme exact en tête)

Pas assez de regroupement : deux lignes de code copiée-collées-modifiées plus de deux fois, ou une ligne répétée 3-4 fois est la manifestation d'une faute de conception en programmation "idéale". Ces "fautes" peuvent être justifiées bien sûr, donc commentées.

Utilisation obscure de vos bouts de code : ça rejoint le point précédent

Pas de chemin clair entre les différents modèles : là pour le coup je suis pas trop d'accord. Le besoin de comprendre un processus en détail et dans son ensemble implique souvent un trop grandes dépendance entre les "modèles". Un système maintenable est un système qu'on n'a pas besoin de comprendre dans sa globalité, "qui appelle qui" etc. C'est une raison pour lesquelles je pense que le "MVVM" de microsoft est une aberration de conception en comparaison au MVC.

Inventer des algorithmes : écrire un algorithme se traduit inévitablement par un warning "complexité cyclomatique" dans checkstyle . Ecrire un algorithme pour encoder un truc, sérialiser, interpréter, ok. Mais c'est pas de la programmation objet, c'est du modulaire.

Bref, il a écrit une manière très intéressante d'expliquer les fondements de l'objet !
Avatar de Uranne-jimmy Uranne-jimmy - Membre expérimenté https://www.developpez.com
le 04/12/2014 à 9:28
J'ai tendance à diminuer le nombre de commentaire pour augmenter la nomination clair de mes variables et fonctions.
N'ayant donc pas l'habitude de lire de commentaire, mon esprit arrive sans soucis à retrouver ma logique bien à moi dans mes programmes ^^
(surtout que vu le temps que j'ai passé dessus, ça a aussi du me marquer)

Par contre le dernier point je comprends pas : Je suis donc en train depuis le début de mon contrat dans mon entreprise de faire le travail d'un futur docteur avec un diplôme de technicien ? J'ai du mal à y croire.
Avatar de I_Pnose I_Pnose - Membre chevronné https://www.developpez.com
le 04/12/2014 à 9:53
Moi non plus je ne suis pas fondamentalement d’accord avec le dernier point (ou alors je n’ai pas saisi le sens du propos). Peut-être que 9 fois sur 10 la roue existe, ça je peux l’admettre, mais de là à décréter que si on invente un algorithme c’est forcément qu’on ne connait pas le bon algorithme à employer, je ne suis pas du tout convaincu.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 04/12/2014 à 10:08
Cet article est simplement un rappel de quelques bonnes pratiques de conception et de développement dont une piqûre de rappel régulière est nécessaire même avec l'expérience.
Rien de révolutionnaire en soit.

Personnellement, ne pas comprendre mon propre code m'arrivait surtout lors de mes études où j'avais tendance à beaucoup développer la nuit (aidé par des cocktails détonnant )...
Par la suite, ça devient tout de même nettement plus rare.

Désormais, je suis plus surpris par le manque de perf ou la consommation mémoire excessive de mon code.
En effet, lorsque je suis concentré sur une fonctionnalité, je me focalise sur la simplicité du code, sa robustesse, sa modularité et le métier, surtout le métier même...
Ce n'est qu'en seconde lecture, quelques semaines après une fois le recule pris, que je constate les évolutions à mettre en place pour améliorer les perf. (et là je rage contre moi-même car à chaque fois cela me paraît évident et que je ne comprends pas comment j'ai pu passer à côté lors du premier jet...)

Développer est une tâche complexe avec énormément de paramètres à prendre en compte.
Dans un monde idéal, on ferait la conception en 3 temps avec une pause à chaque fois et le développeur ne serait pas celui qui effectue la conception afin d'avoir une regard critique impartiale sur celle-ci.
Malheureusement, le rythme des projets ne le permet pas...
Avatar de Xinu2010 Xinu2010 - Membre averti https://www.developpez.com
le 04/12/2014 à 10:24
Il m'arrive de reprendre le code de vieux projets personnels en ayant fait une pause de plusieurs années, et je ne les trouve jamais incompréhensible. La plupart du temps ma réaction est "tien ça c'est pas propre, j'aurais du le faire comme ça". J'ai tendance à essayer de soigner mon code, est comme Uranne-jimmy je limite le nombre de commentaire; je pense qu'une bonne pratique est d'utiliser les commentaires uniquement pour clarifier l'intention (le "pourquoi"), et de clarifier le "comment" en utilisant une nomenclature descriptive des variables, fonctions, objets, etc.

Après dans un cadre pro je tombe parfois sur de tels torchons que ça ne m'étonnerais pas que leurs auteurs les trouves eux même incompréhensible au moment de leurs écritures...
Avatar de AoCannaille AoCannaille - Membre expérimenté https://www.developpez.com
le 04/12/2014 à 10:42
Citation Envoyé par Saverok  Voir le message

Désormais, je suis plus surpris par le manque de perf ou la consommation mémoire excessive de mon code.
En effet, lorsque je suis concentré sur une fonctionnalité, je me focalise sur la simplicité du code, sa robustesse, sa modularité et le métier, surtout le métier même...
Ce n'est qu'en seconde lecture, quelques semaines après une fois le recule pris, que je constate les évolutions à mettre en place pour améliorer les perf. (et là je rage contre moi-même car à chaque fois cela me paraît évident et que je ne comprends pas comment j'ai pu passer à côté lors du premier jet...)

C'est tout a fait normal, Knuth (qui n'est pas juste 'un développeur qui se penche sur une question') nous met en garde contre les optimisations prématurées et résume les étapes de l'algorithmie comme cela :
1. Make it work.
2. Make it right.
3. Make it fast.

Avatar de temoanatini temoanatini - Membre averti https://www.developpez.com
le 04/12/2014 à 11:28
Inventer des algorithmes : « dans presque tous les cas, il existe des algorithmes qui peuvent être mis ensemble pour résoudre votre problème ». Programmer consiste donc à choisir des algorithmes existants dans la bonne combinaison pour résoudre un problème. Selon lui, « si vous inventez de nouveaux algorithmes, c’est soit que vous ne connaissez pas le bon algorithme à employer, soit vous travaillez sur une thèse de doctorat ».

Contrairement à certains, je suis assez d'accord avec ça.

Je pense que vous n'avez peut-être pas saisi ce qu'il a voulu dire ici.

Peut-être peut-on reformuler comme ceci : "demandez-vous combien de fois vous avez écrit du code pour répondre à un besoin d'une manière qui n'a jamais été utilisée par personne depuis que la programmation existe".

A moins que vous travailliez dans des domaines "relativement récents" ou très pointus tels que le traitement de l'image, la programmation parallèle, l'intelligence artificielle...
Avatar de dfiad77pro dfiad77pro - Membre éprouvé https://www.developpez.com
le 04/12/2014 à 11:36
Citation Envoyé par temoanatini  Voir le message
Contrairement à certains, je suis assez d'accord avec ça.

Je pense que vous n'avez peut-être pas saisi ce qu'il a voulu dire ici.

Peut-être peut-on reformuler comme ceci : "demandez-vous combien de fois vous avez écrit du code pour répondre à un besoin d'une manière qui n'a jamais été utilisée par personne depuis que la programmation existe".

A moins que vous travailliez dans des domaines "relativement récents" ou très pointus tels que le traitement de l'image, la programmation parallèle, l'intelligence artificielle...


Dans certains domaines spécifiques (transport, etc) ,
le développeur est fortement axé métier et est amené à concevoir ses propres algorithmes pour répondre à une problématique particulière ( changement de loi, moteur de calcul , etc).

Les algorithmes standard ( parcours de graphe etc.) restent déjà établis mais leur utilisation conjointe donne un algorithme global qui n'existe probablement pas...
Les propriétés mathématiques restent connues (statistiques, etc), mais c'est l'axe métier qui sera considéré comme un algorithme à part.
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 04/12/2014 à 11:49
Citation Envoyé par dfiad77pro  Voir le message
Dans certains domaines spécifiques (transport, etc) ,
le développeur est fortement axé métier et est amené à concevoir ses propres algorithmes pour répondre à une problématique particulière ( changement de loi, moteur de calcul , etc).

Les algorithmes standard ( parcours de graphe etc.) restent déjà établis mais leur utilisation conjointe donne un algorithme global qui n'existe probablement pas...
Les propriétés mathématiques restent connues (statistiques, etc), mais c'est l'axe métier qui sera considéré comme un algorithme à part.

De ce que je comprends, tu dis la même choses que l'auteur
C'est l'orchestration des algo qui est à développer (et leur paramétrage) mais pris unitairement, ils existent déjà quelques parts
Offres d'emploi IT
Réalité augmentée (h/f)
Atos - Auvergne - Clermont-Ferrand (63000)
Développeur LIFERAY confirmé à sénior
DEVOTEAM SA - Ile de France - Clamart (92140)
Concepteur/Développeur .NET (H/F)
Atos Technology Services - Provence Alpes Côte d'Azur - Aix en Provence

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil