IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

25PARTAGES

3  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Shepard
Membre expérimenté https://www.developpez.com
Le 03/12/2014 à 23:15
Quel soulagement d'actuellement travailler sur ma thèse de doctorat !
3  0 
Avatar de 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.
3  0 
Avatar de 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...
3  0 
Avatar de AoCannaille
Expert confirmé 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.
3  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 10/12/2014 à 17:13
Tu veux que je commente ??

Allons-y...

  1. En ce qui concerne la référence aux langages objets, c'est justement ce que dit le posteur en question :

    Citation Envoyé par Washmid Voir le message
    Ca résume la philosophie de la programmation objet
    ..
    Bref, il a écrit une manière très intéressante d'expliquer les fondements de l'objet !
    que je critique...
  2. Secondo,

    Citation Envoyé par Washmid Voir le message
    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)
    Ah oui ???? Pourtant quand on regarde des applis en C++ ou Java, je ne voit pas moins de complexité.. ni moins de dépendances, voire le contraire..

    Car la limitation des dépendances se fait par des "classes" propres, et je suis au regret pour Washmid de lui apprendre que la notion d'objet, de classes, etc n'est pas propre aux LANGAGES objets, mais existe depuis plus de 40 ans en procédural, que ce soit en C, Fortran, etc etc.. (X11 est à base d'objets, mais écrit en C, comme C++)

    C'est le principe de la CONCEPTION orientée objet, pas des langages..

    Et quand on voit les dépendances de tout programme C++ de bonne taille avec Boost par exemple, son "argument" prend l'eau... Ou dans n'importe quelle compliation d'un programme complexe, qu'il soit en Java ou en C++...

    Citation Envoyé par Washmid Voir le message
    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)
    Et quand on va sur le forum ALM et qu'on regarde la partie "architecture" ou "modèles", on s'aperçoit que cette "mauvaise traduction" est extrêmement répandue..... Simplement pace que justement il y a mille et une façons de concevoir quelque chose, de le découper, et que la logique de l'un n'est pas forcément la logique de l'autre... Et qu'avoir un "modèle mental" n'est même pas significatif.. Encore faut-il qu'il soit bon... Quant à le traduire, dans n'importe quel langage, ça prend une rigueur...

    Citation Envoyé par Washmid Voir le message
    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.
    Voui, ben ça dépend fortement.... Parce que avoir les 2 mêmes lignes de code, mais appliquées à des choses différentes, vont être plus simples à comprendre telles quelles que si on a regroupé sous quelque chose qui oblige quand on relit le code à aller chercher dans tel ou tel autre module ce que fait cette "fonction", "classe", "méthode", etc, qui aura alors forcément un nom générique pas forcément adapté au contexte précis...

    Citation Envoyé par Washmid Voir le message
    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.
    Tout ceci est un charabia incompréhensiible.. Sur quoi se base-t-il pour dire : "Le besoin de comprendre un processus en détail et dans son ensemble implique souvent un trop grandes dépendance entre les "modèles"" ?? ou encore plus fort : "Un système maintenable est un système qu'on n'a pas besoin de comprendre dans sa globalité" ???? Quel est le rapport ??? ou la justification ???

    Et en quoi le MVC est-il un modèle "universel" et "compréhensible par tout le monde", en dehors de ceux qui l'ont appris ????

    En quoi un sytème maintenable est-il défini par le fait qu'on ne comprend pas sa globalité ???

    Citation Envoyé par Washmid Voir le message
    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.
    Encore une fois, sur quoi se base-t-il pour affirmer "écrire un algorithme se traduit inévitablement par un warning "complexité cyclomatique"" ??? Ou encore plus fort : "Mais c'est pas de la programmation objet, c'est du modulaire" ??

    Ce monsieur n'a sans doute jamais fait de maths, ou d'algorithmes réellement complexes... En quoi est-ce modulaire ou objet ou quoi que ce soit en rapport avec un modèle de programmation ???? Un algorithme est un algorithme, une suite d'opérations logiques pour partant d'un départ arriver à un résultat...

    Quel est le rapport avec de la programmation objet ??? En quoi une programmation objet devrait-elle se passer "d'algorithme" ????


Sans parler de son introduction et conclusion cités au début de ce post... C'est hors sujet.. Tout ce que dit le bloggeur, c'est rappeler des règles de bases, qui lui semblent essentielles.. On peut en discuter, mais elles ne dépendent pas, ni ne soutiennent, une quelcquonque manière / un quelconque paradigme de programmation....

C'est en ça que je dis et maintiens que c'est idiot comme réflexion...
2  0 
Avatar de ChristianRoberge
Membre habitué https://www.developpez.com
Le 13/12/2014 à 17:08
Je suis d'accord sur les points qui nous fait oublier ce que notre code fait. Par contre, pour moi, les causes sous-jacentes sont principalement: le manque de maitrise du problème à résoudre et des solutions existantes pouvant s'y rapporter. Les spécifications à atteindre sont souvent imprécises, et même changent en cours de projet. Les fonctionnalités provenant de librairie sont mal utilisés car nous ne connaissons mal ce que fait réellement ces algorithmes. Ajoutons à ce contexte le stress des échéanciers trop court et nous venons de perdre le contrôle sur notre code et de notre projet. Beaucoup trop d'informaticiens se targuent d'être d'excellent programmeurs parce qu'ils connaissent à fond tel langage ou librairie. À cela je leur répond un diction culinaire: Connaître les ingrédients, ne fais pas de vous un grand chef!
Personne maitrise réellement l'ART de la programmation (qui nous éviterait les problèmes mentionnés ci-haut!). À ceux qui pensent que ces propos sont pessimistes, je leur réponds qu'il y a toujours place à l'amélioration. Je souhaite à tous de rester humbles devant les problèmes et les autres. L'humilité nous permet de progresser et c'est le point le plus important pour des informaticiens qui ont à s'adapter à un monde en perpétuelle changement.
2  0 
Avatar de Nebulix
Membre expérimenté https://www.developpez.com
Le 13/05/2015 à 13:44
Il m'arrive souvent de reprendre un code après quelques années et de n'y rien comprendre au premier abord. La raison est plus simple que tout ce discours : quand on vient d'écrire un code ou de le comprendre de nouveau, il apparait tout simplement "évident", on ne sait plus "où est le problème". Et les commentaires qu'on peut rajouter sont redondants. La solution, qui permet de coder plus facilement et de comprendre même longtemps après est de commenter AVANT de coder.
2  0 
Avatar de 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...
1  0 
Avatar de 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...
1  0 
Avatar de 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
1  0