Discussion :

[Idelways]

Trouvez-vous souvent le code des autres mauvais ?
Une développeuse décrit l'évolution de sa perception du travail des autres



Sara est une développeuse .NET qui se décrit comme une « Gerd » (Nerd au féminin).

Son blog est plutôt flashy mais le fond y est sérieux (pas triste, juste sérieux). Elle y parle de son expérience quotidienne du développement. Et parmi ses billets, l'un d'eux est particulièrement pertinent. Sara y décrit l'évolution de sa perception du code sources des autres.

Une expérience que de nombreux développeurs (et développeuses donc) ont déjà vécue.

Au départ, avoue Sara, elle trouvait systématiquement le travail des autres mauvais. Elle reprenait le code « from scratch » dès le premier coup d'œil.

Mais bien souvent, une fois le travail refait, son premier jugement devait être modéré. Ce n'est qu'après avoir tout ré-écrit qu'elle arrive à comprendre quelles contraintes ont obligé ses prédécesseurs à coder d'une manière qu'elle avait, au premier abord, qualifiée de mauvaise.

Avec l'expérience, nous dit-elle, elle a appris à ne jamais critiquer le travail des autres. Tout du moins pas avant de comprendre le projet en entier et en cerner toutes les contraintes.

Cette modération a du bon. Elle évite par exemple de se demander qui a bien pu coder ce « truc horrible ». Avant de réaliser que c'est soi-même, quelques mois plus tôt.

Elle permet également de ne pas trop « avoir les chevilles qui gonflent » en se trouvant systématiquement meilleur que ses confrères.

Une modération qui se ferait (trop) rare ?


Et vous ?

Votre travail a-t-il été injustement critiqué par un tiers ? Comment faites-vous pour protéger votre réputation en livrant vos sources ?

Trouvez-vous souvent (systématiquement) le code source des autres mauvais ? Ou en tout cas moins bon que ce que vous auriez pu faire ?
Comment expliquez-vous ce phénomène ? Est-il lié au genre (homme-femme) ou pas du tout ?

Source : Your code sucks


En collaboration avec Gordon Fowler

[FERDIKAM]

Je suis tout à fait d'accord avec elle. En fait c'est l'esprit d'humilité qu'il faut cultiver pour être encore meilleur. Moi-même j'ai rencontré des codes bizarres mais fonctionnels. Et quand il a fallu travailler, la-dessus j'étais comme elle obligé de tout recommencer à coder et dénigrer le travail des prédécesseurs. Mais on comprend réellement les motivations des autres qui ont pu mener à ce boulot. Donc lorsque je reprends le travail d'un autre et que le client essaie de le dénigrer, je trouve toujours une raison qui l'amène à comprendre les choix de l'autre et ce n'est qu'une contribution en vue de l'amélioration.

[Klaim]

L'humilité a toujours fait partie des bonnes armes mentales des bons programmeurs, et va dans le sens de l'ego-less programming.

[eldran64]

La modération et l'humilité sont qualités essentielles pour les développeurs et les développeuses. Sans celles-ci, le travail en équipe (qui est essentiel pour les développeurs(euses)) ne peut pas se faire correctement.

[Arpheus]

Comment faites-vous pour protéger votre réputation en livrant vos sources ?

En voilà une bonne question.
Ma réponse est ... eh bien rien
Tout dépend de l'état d'esprit de la personne qui va les lire.

[CheryBen]

Comment expliquez-vous ce phénomène ? Est-il lié au genre (homme-femme) ou pas du tout ?

C'est bien connu que les femmes ne savent pas coder. ...

Les langages évoluent également, il arrive parfois que l'on tombe sur du très vieux code, écrit à l'époque avec les possibilités offertes par le langage.
Par exemple je travail sur un projet dont les 1ères classes ont été faites en java 1.2, et maintenant on utilise la version 1.5. Il y a eu énormément de nouveautés depuis qui facilitent la vie du développeur ou améliorent la syntaxe.

[sevyc64]

Il faut effectivement faire la différence entre du code vraiment mauvais et du code "Pas-Comme-Je-L'aurais-Fais-Moi"

Le premier est assez reconnaissable et jugé unanimement par une majorité de développeur. Généralement d'ailleurs, il n'y a pas besoin d'analyser les contraintes du projet pour le reconnaitre mauvais, et toutes les parties de code, même les plus simples souffrent du même défaut ainsi que tous les code du même auteur.

Pour le second, il peut effectivement arrivé de l'analyser comme mauvais parce que tout simplement dans la première impression, on en comprend pas la logique.Mais tout bon développeur, dans ce cas, essaiera de comprendre ce code avant d'avoir un jugement définitif. Et les cas ne sont pas rare de s'appercevoir que, même si c'est pas codé comme on l'aurait fait non même, le code n'en reste pas moins bon, voire original, et même parfois meilleur que ce que l'on aurait pu faire.

[JeffPalmier]

Il est vrai que des fois, on tombe sur un code qui parait assez "dégeu" au premier abord, mais en fait, on se rend compte que c'était la seule solution pour que tout tourne nikel.

On s'est tous retrouvé confronté à des erreurs incompréhensibles, et une fois que ça marche, même si c'est super sale, on le laisse, ça marche lol

[_skip]

J'ai l'impression de voir souvent des trucs pas terribles.

Ce que j'en sais c'est qu'il est parfois (trop) facile de juger un travail fini sans avoir connu le contexte réel de celui-ci.
J'essaie toujours de me mettre dans la situation de la personne, avait-elle prévu un certain design et ensuite des modifications imprévues en dernière minute l'aurait forcée à faire des compromis? Ceci ajouté au manque de temps, délais pressants, intégration à l'existant etc...

Qui ne s'est jamais dit : "tiens j'aurai pu faire comme ci, gérer ça autrement etc..." après coup à la fin d'un projet?

Niveau code, mon seul critère est qu'il soit écrit de façon simple, des méthodes assez courtes, facilement unit-testable avec un rôle bien défini et une gestion d'erreur propre.

[el_slapper]

(.../...)

Votre travail a-t-il été injustement critiqué par un tiers ? Comment faites-vous pour protéger votre réputation en livrant vos sources ?

jamais. Je ne suis plus là quand mon code est relu. C'est sans doute un tort, d'ailleurs, je suppose que le regard des autres m'en apprendrais beaucoup.

Trouvez-vous souvent (systématiquement) le code source des autres mauvais ? Ou en tout cas moins bon que ce que vous auriez pu faire ?

Souvent. Pas toujours. Mais j'ai tendance à être compréhensif : souvent le code que je récupère a été créé pour répondre à un cas simple, puis étiré à un périmètre souvent au-delà du raisonnable.....

Comment expliquez-vous ce phénomène ? Est-il lié au genre (homme-femme) ou pas du tout ?

pas du tout. Il y a des gorets des deux genres. Et sinon, même le code propre n'est pas tel qu'on l'aurait fait, là, maintenant, et on a toujours des choses à redire(ou on croit en avoir).

[sylez]

Je suis sans doute un poil égocentrique (rêveur, utopique, etc ), mais je pense qu'un beau code est un code que l'on comprend dès la première lecture.

Il y'a potentiellement autant de beaux codes que de développeurs.

Par contre c'est assez impalpable; c'est un critère général il faut un certain "équilibre".

Le mauvais code c'est l'inverse ce sont les détails qui choquent :
noms de variables courts ou obscures, méthodes très longues, utilisation abusive exception a la place de retour, etc...

[atb]

Je suis assez d’accord avec sevyc64. On sait toute de suite si on a un mauvais code en face ou pas. Si la personne a utilisé des opérations dangereuses, mal géré ces exceptions,….

Par contre, je trouve immature de critiquer facilement le code des autres, surtout le faire en public (ou devant ces anciens collègues,…). Car le contexte dans lequel le projet a été développé peut changer radicalement.

Il m’est arrivé de coder une application tout simple qui répondait à un besoin basique. Je n’avais que 4 jours pour le faire. Un an plus tard mon ancienne boite a embauché un développeur qui n’a pas hésité à critiquer sévèrement mon travail. En disant que j’avais codé comme un porc. Et que je pouvais rajouter plus de fonctionnalités …

C’est triste mais le gars a passé des semaines à recoder le tout mais n’arrivait pas à retrouver les bons chiffres. Comme quoi à vouloir perfectionner le travail des autres, on passe à coté du principal.

[bugsan]

Je suis un peu étonné.

Il y a pourtant des critères objectifs pour juger un code source, un tas d'outils, de bonnes pratiques, un tas de livres écrits par les Guru de l'informatique. Et avec les années les anti-patterns de conception et d'architecture sont de mieux en mieux connus.

- Single responsibility / Separation of concerns
- Open/closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
- Don't repeat yourself
- Keep it simple, Stupid
- PMD
- Checkstyle
- Findbugs
- etc ...

Liste exhaustive (très intéressante au passage) :
http://en.wikipedia.org/wiki/List_of...t_philosophies
http://en.wikipedia.org/wiki/Anti_pattern

La lisibilité du code n'est pas non plus quelque chose de subjectif. Ce que l'on appelle le "relearning", où comment écrire son code de façon à réduire le temps nécessaire à le réapprendre des mois plus tard (pour s'y replonger).


Bien sur aucun code n'est parfait et je suis très loin d'appliquer moi même tout ce que je viens d'énumérer.
Dire qu'un code source est "tordu" ou "mauvais" n'est pas un argument acceptable à mon avis. Il faut pouvoir expliquer pourquoi, de façon rationnelle.

[killruana]

Dans la boite où j'ai bossé cet été le code du boss était vraiment horrible. Mais pas dans la logique, car au contraire, son code révélait une certaine intelligence et réflexion (quoi que des fois... ), mais la présentation était horrible Entre le nom des variables à un caractère, les indentions aléatoires, les accolades placés au petit bonheur la chance... -_-'
De l'autre coté y'avait le stagiaire SupInfo de 4eme année qui apprenait le PHP. Le code était présenté nickel (enfin, si on aime la notation BSD), mais point de vu logique c'était parfois un peu funky
Mais que voulez-vous faire dans ces conditions ?

[Grimly_old]

Aucun code n'est mauvais (sauf ceux qui sont de vraies machines de Goldberg). Le problème que je rencontre dans 99% des cas où j'annonce qu'un code est "merdique", c'est à cause d'un manque conséquent de documentation coté développeur.

[Nebulix]

... ne jamais critiquer le travail des autres. Tout du moins pas avant de comprendre ...

Vous voulez faire la révolution ? Notre société ne tiendrait pas longtemps si on diffusait ce genre de principe. Ne pas se proclamer le meilleur, ne pas jouer la compétition permanente ? Ne pas acheter de grosse bagnole avant de comprendre qu'une petite rend le même service ? Ne pas acheter de Rolex parce qu'une Sw*** donne l'heure aussi bien ?
Nicolas, Brice, au secours !

[verbose]

Je n'ai pas encore une grande expérience, mais j'ai pu constater que bien souvent, lorsque le code est mauvais, c'est soit parce qu'il n'a pas été modélisé ou du moins fait l'objet d'une réflexion quant à son architecture, soit parce que plusieurs développeurs sont passés par là avec chacun sa propre vision du problème.

Dans ce dernier cas, la cause profonde vient des spécifications qui sont souvent incomplètes. Sur un seul des projets sur lesquels j'ai bossé les spécifications incluaient des diagrammes et autres règles de gestion. Pour tous les autres, il fallait décortiquer une documentation souvent mal écrite ou mal organisée voire quasi inexistante (si si !!!)

Il y a aussi une autre cause. Il y a des développeurs qui maîtrisent mal certaines notions comme les design patterns. Personnellement je n'en connais que quelques uns parmi les plus répandus, mais il me semble que le plus important est d'être sensibilisé à cette problématique.

La maîtrise du langage constitue également une source de problème. Il m'est déjà arrivé de devoir expliquer ce que fait le mot-clé "continue", ou encore d'apprendre que l'on peut étiqueter une boucle. Je vois aussi dans certaines contributions que tout le monde ne sait pas utiliser else if. Bref, il faut savoir faire preuve d'humilité, mais aussi être pédagogue

[pmithrandir]

Je n'ai pas encore une grande expérience, mais j'ai pu constater que bien souvent, lorsque le code est mauvais, c'est soit parce qu'il n'a pas été modélisé ou du moins fait l'objet d'une réflexion quant à son architecture, soit parce que plusieurs développeurs sont passés par là avec chacun sa propre vision du problème.

Dans mon cas, à chaque fois que je trouve le code mauvais, c'est parce que les gens réinventent la roue.

L'autre jour, j'ai par exemple eu un ticket sur le dev d'un collège qui consistait à faire de la pagination de resultat.

Autant ma première reaction a été de savoir comment le faire avec le framework, autant la sienne a été de coder directement une pagination faite maison.
Bref, le truc que je devais developper allait me prendre des heures le temps de comprendre son code, donc j'ai écrit 2 lignes de code qui remplacait son code pour mettre en pagination automatique et zou, c'était fini.(il fallait ajouter un tri par colonne)

On a le même genre de problème avec l'emplacement du code, tout dans la vue par exemple.

Et en général, plus les gens tapent vite, moins ça va bien.
A contrario, plus ils utilisent un papier et un crayon, plus ça se passe bien.

[berurier74]

Du code mauvais :
- une seule grande procédure qui fait tout
- ne pas nommer de manière explicite les variables
- ne mettre aucun commentaire

Je n'ai aucune humilité avec ce mauvais code. Je jette tout et je recommence. Après... Le reste est pas toujours si simple et là, ok pour l'humilité.

[DrHelmut]

Un mauvais code, pour moi, c'est avant tout un code incompréhensible : pas de commentaires, des méthodes de 2000 lignes.... Bref quand c'est très dur de passer derrière lorsqu'il faut le corriger ou le faire évoluer.

Un noob (junior, stagiaire) qui m'écrit des conneries énormes (en termes d'optimisation ou de connaissance du language) mais qui au moins m'a fait un code bien structuré => pour moi c bon : le code est fonctionnel bien que pas top, et on peut repasser derrière sans s'arracher les cheveux à essayer de comprendre ce que le developpeur a voulu faire.
Peu importe que le gars réinvente la roue, s'il le fait c'est qu'il n'a pas bien été formé au language, aux frameworks... ça s'apprend ça !
Alors que les habitudes de structuration du code, quand on en a pris de mauvaise, c'est limite foutu - y'a plus rien à faire

D'ailleurs, a contrario, un senior/expert qui m'écrit un bousin ultra-optimisé aux perfs de ouf... mais que lui seul peu comprendre, je lui balance son code à la gueule sans pitié si on me demande d'y toucher !