Trouvez-vous souvent le code des autres mauvais ?
Une développeuse décrit l'évolution de sa perception et prône l'humilité

Le , par Idelways, Expert éminent sénior
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


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


 Poster une réponse

Avatar de bifur bifur - Membre averti https://www.developpez.com
le 19/10/2010 à 11:48
je pense qu'il est impossible de faire un code qui soit facilement compréhensible par autrui (en tout cas j'en suis incapable) a moins de faire un tas de commentaire dans la source

j'essaye de décrire le plus précisément chaque mini procédure ou fonction avec les registres uttilisé, ainsi que les variable. c'est le minimum lorsque que l'on veut pouvoir reprend un programme abandonner depuis quelques mois (et je ne parle même pas de travailler en équipe)

je ne juge pas trop les codes des autres, je considère que mes programme sont toujours améliorable, qu'il faut toujours reécrire un bout ou rajouter une fonction. il me faut minimum 3 version avant de considéré un programme comme aboutit

l'important c'est que le programme fonctionne, vite et bien
Avatar de mayeulak mayeulak - Candidat au Club https://www.developpez.com
le 27/10/2010 à 4:48
j'ai longtemps crus que j'étais fou à ne pas aimer le travail des autres développeurs que je trouve la plus part du temps médiocre ^^.
non mais, parfois on ne support plus les indentations mal appliquées de ses collègues :-D. alors allez savoir s'il s'agissait d'une erreur dans le code lui même hahaha. ça va chier!

merci de m'avoir rassurer que tout va bien
Avatar de smoufid smoufid - Membre régulier https://www.developpez.com
le 28/10/2010 à 0:32
bonjour,
il faut etre humble et accepter le travail des autres.
Avatar de duboisa duboisa - Membre régulier https://www.developpez.com
le 21/11/2010 à 17:18
je suis assez s'accord avec _skip
c'est vrai qu'un code écrit par un débutant peut être difficile à lire (et à valider) idem par un débutant + 2 (qui essaie de factoriser à mort)
mais avec l'expérience on reconnait le genre d'auteur, et on s'adapte.
la revue de code est un exercice.
Avatar de atc666 atc666 - Membre régulier https://www.developpez.com
le 10/04/2011 à 4:51
quand je lit vos commentaires je me dit que pour vous la chose la plus importante c est que ça soit facile a lire ...
donc si je vous comprend bien , si le code est lent et totalement dépourvu de toutes formes d optimisation , mais qu'il est facile a lire et simple a comprendre c est top ?
j ai vu parmi vos commentaires quelqu’un qui écrit que si il trouve un code qui est top rapide mais difficile a comprendre , elle le jetterai a la tête de celui qui l as "pondu" ... mais pourquoi ne pas au contraire justement faire l'effort de comprendre ce code et d en tirer des leçons pour améliorer la vitesse de son propre code ?
je pense que beaucoup se place uniquement de leur point de vue et jamais de celui du client.
le code "spaghetti" je comprend qu on aime pas ca car c est rarement rapide comme code voir meme je pense jamais
Avatar de ymoreau ymoreau - Membre émérite https://www.developpez.com
le 11/04/2011 à 13:48
C'est un vaste débat que tu ouvres, mais je dirais que dans l'opinion générale le cout de développement est bien plus cher que le cout d'exécution. Avec les machines qu'on a de nos jours les optimisations au niveau code (et pas au niveau architecture ou conception) sont, je pense, négligeables en gain d'exécution. Alors que la compréhension du code peut faire gagner beaucoup temps pour ceux qui devront le faire évoluer, et ce temps là coute cher (au client aussi d'ailleurs).
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 11/04/2011 à 14:33
L'explication requiert en fait un peu plus de bon sens basé sur l'expérience et des faits :

- un code facile à comprendre est plus facile à modifier parcequ'on comprends l'intention et donc on peut l'ajuster en maintenant cette intention;
- un code difficile à lire est source de problèmes parcequ'on ne comprends pas facilement l'intention, ce qui est rééllement voulu;
- par conséquent, il est plus facile d'avoir un code lisible au départ et de le rendre illisible pour régler des soucis de performance, si il y en a;
- de plus, la lisibilité du code n'est pas forcément lié à la rapidité de celui-ci : il y a des tas d'exemples de code qui sont plus rapide quand ils sont écrit simplement, parceque comme ils sont plus facile à lire aussi pour le compilateur ou l'interpreteur, il devient plus facile à optimiser (parceque connaitre les intention permet de déterminer ce qu'on considère comme acquis, les invariants).

Donc en gros, l'idée c'est de toujours écrire le plus lisiblement possible, en pensant au mec (qui peut être soit-même) qui reviendra sur ce code dans 3 mois et qui ne saura rien dessus. (Oui, vous aurez oublié).

Comme ça, il aura de meilleures chances de modifer le code dans le bon sens, de rendre potentiellement le code plus performant si c'est le but de la modification.

Et enfin, ceux qui rejettent le code pas clair même si plus performant ont raison sauf si la performance est requise pour le code en question. Cela dit, je n'ai jamais vu de code très performant qui ne pouvait pas être un peu plus clair que sa version "brute". Ya toujours moyen de rendrre plus clair sans changer les instructions finales. Seulement ça requiert certainement plus d'expérience.
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 11/04/2011 à 14:45
Citation Envoyé par atc666  Voir le message
quand je lit vos commentaires je me dit que pour vous la chose la plus importante c est que ça soit facile a lire ...
donc si je vous comprend bien , si le code est lent et totalement dépourvu de toutes formes d optimisation , mais qu'il est facile a lire et simple a comprendre c est top ?
j ai vu parmi vos commentaires quelqu’un qui écrit que si il trouve un code qui est top rapide mais difficile a comprendre , elle le jetterai a la tête de celui qui l as "pondu" ... mais pourquoi ne pas au contraire justement faire l'effort de comprendre ce code et d en tirer des leçons pour améliorer la vitesse de son propre code ?
je pense que beaucoup se place uniquement de leur point de vue et jamais de celui du client.
le code "spaghetti" je comprend qu on aime pas ca car c est rarement rapide comme code voir meme je pense jamais

tout dépend du contexte, si c'est pour gagner 1/2 seconde sur une appli de gestion dont la force est dans la gestion de données techniques particulièrement complexes, oui il faut jeter le code ultra optimisé qui rend les choses incompréhensibles.

maintenant si le temps de réaction de l'application est critique, effectivement on sacrifiera la lisibilité pour gagner les précieuses millisecondes dont on a besoin.

mais dans 90% des cas c'est l'algorithme et les hypothèses de départ qui sont à revoir, pas les lignes de code.
Avatar de SirDarken SirDarken - Membre émérite https://www.developpez.com
le 11/04/2011 à 15:49
Pour ma part, je suis toujours entrain de raler sur le code que j'ai moi même pondu.

Ca fait deux ans que je code, et pourtant chaque jour j'apprend des trucs, donc je suis plutot cool face au code de mes confrères/consoeurs même si il m'arrive de m'arracher les cheveux à reprendre le code.
Avatar de Klaim Klaim - Membre expert https://www.developpez.com
le 11/04/2011 à 16:04
Des tas de gens avec 10 ou 20 ans d'experience disent pareil. On finiras pas d'apprendre dans ce métier (et quelque part, tant mieu).
Avatar de zaventem zaventem - Membre expérimenté https://www.developpez.com
le 12/04/2011 à 10:24
Citation Envoyé par atc666  Voir le message
quand je lit vos commentaires je me dit que pour vous la chose la plus importante c est que ça soit facile a lire ...

Ce qui compte, c'est qu'il soit le plus facile à lire possible.

Citation Envoyé par atc666  Voir le message
donc si je vous comprend bien , si le code est lent et totalement dépourvu de toutes formes d optimisation , mais qu'il est facile a lire et simple a comprendre c est top ?

Étrangement, tous les codes lents et non-optimisés que j'ai vu étaient tout sauf clairs, structurés et faciles à comprendre. Les codes faciles à comprendre sont (en règle générale) issus d'une vraie réflexion sur les algorithmes utilisés, sur une bonne compréhension de la problématique et lorsqu'un passage plus tricky est nécessaire des quelques mots de commentaires qui disent ce que fait le code et pourquoi.
Offres d'emploi IT
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

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