Discussion :

[Invité]

Je pense qu'il ne faut pas systématiquement tout réécrire ni refuser le code not made in home surtout quand les raisons sont purement esthétiques. Dans tous les cas, j'encourage la critique avisée que l'on peut formuler quand on connaît bien les tenants et les aboutissants. En fonction des contraintes de temps entre autres, j'essaie de me contenter de modifications mineures. Si je devais tout réécrire tout le temps, j'y passerais un temps fou, ce n'est tout bonnement pas raisonnable.

Récemment, j'avais besoin d'un importeur de modèles au format MD2 pour le moteur Ardor3D, un des principaux développeurs du moteur m'avait dit qu'il n'accepterait d'intégrer qu'un importeur réécrit de zéro et non un importeur porté à partir du code source de JMonkeyEngine 2. J'ai été humble, je me suis dit que je ne ferais sûrement pas mieux que ceux qui avaient écrit cet importeur pour JMonkeyEngine 2, je l'ai porté pour Ardor3D, j'ai changé l'agencement du code, la répartition des rôles mais je n'ai pas tout réécrit.
Au final, l'importeur de modèles MD2 pour Ardor3D marche très bien, j'ai gagné un temps fou en refusant de le réécrire complètement et j'ai convaincu ce développeur récalcitrant de l'intégrer dans son moteur pour de bon.

A quoi sert-il de mettre son code source sous licence libre à disposition de tout le monde si les développeurs qui pourraient s'en servir ne pensent qu'à tout jeter à la poubelle et tout reprendre de zéro? Personnellement, je ne fais pas du développement de logiciels libres pour la frime, j'apporte un certain soin à mon code pour le rendre intelligible.

[clochettes]

Lors de ma première expérience pro, je suis arrivée sur du code horrible! Une architecture pas claire, des fonctions à rallonge... Très difficile de s'y retrouver.
Après quelques mois où j'ai pu voir que les cahiers des charges évoluaient tout les jours, j'ai revu mon premier avis sur le code existant. Quand on sait dès le début où on va, on peut faire un code lisible et maintenable par des tiers, en revanche, ça devient très difficile dans certaines conditions.

[ShaiLeTroll]

Alors oui, probablement, ce message va vous faire penser que je suis un type orgueilleux et vantard... Et vous aurez raison. Je suis bien connu pour ça parmi mes proches.

Connaissant tes travaux, tu peux te le permettre et je suis comme toi, je commencer par gueuler (par plaisir ?) puis je me modère, entre Dr. House et Malcom mais avec nettement moins de Génie !

Il me semble qu'il y a confusion entre "bon" code et "beau" code.
... j'ai bien assez de boulot à porter un regard critique sur mes propres sources).

+1 !
Entièrement d'accord avec ces deux points, je fais la confusion le 1er, pour le moment, j'estime avoir fait du "bon" code mais je n'ai encore jamais trouver "beau", j'y vois toujours un défaut soit trop complexe, pas assez testé, pas économique en ressource... on doit toujours fait un compris qualité du code / Budget mais faut être honnête, certains oublient les deux !

J'ai personnellement essayé de modèliser en UML (j'ai suivi des cours) et d'y associer les patterns qui vont avec ... j'ai trouvé une bonne dizaine de méthodes différentes pour implémenter la même pattern (du moins ce que l'on croit être une pattern, je suis un spécialite pour pondre un "strategy" n'importe quand et n'importe où , c'est surtout lié que dans mon boulot, j'ai souvent besoin d'inter-opérabilité entre nos progiciels et ceux de partenaire ayant tous leurs protocoles), au final, le code est compliqué, retord, et pas si loin d'un code spaghetti, parce que le code n'est pas exactement comme la Spec qui évidemment changé entre temps !

[mclane1]

La critique est facile. Est trop souvent, je tombe dans le piege. C'est vrai qu'ensuite, une fois le "code horrible" compris, on s'apperçoit qu'on aurait pu faire pareil.
Ce qu'il faut souligner, c'est la difficulté de trouver des "lignes de bonne conduites" sur un langage de programmation pour ne pas tomber dans certain piège. J'ai été "victime" d'une revu de code... La réponse a été : c'est très bien mais attention sur ces points... Mettre les constantes avant dans un test d'égalité (même avec un null), utilisation du break (qu'on m'avait dis de proscrire à la fac), le "is" au lieu du "get" sur les boolean, l'utilisation d'outils que je ne connaissais pas... J'en connaissais les 3/4, mais le 1/4 restant a été bon à apprendre, et les 3/4, une bonne piqure de rappel. Alors avant de regarder la paille dans l'oeil du voisin, mieux vaut commencer par regarder la poutre dans son oeil.

[Lucas Brazi]

Un bon code est un code qui est comprehensible et maintenable par un tiers.

Si des ecarts sont fait ou le code est trop complexe, trois mots : commenter, commenter, commenter !

Si la maintenance ne peut pas etre faite par un tiers : réécriture.

Normalement, un semblant d'architecture doit preceder le code meme pour les petits projets : le fait de realiser un petit diagramme de sequence aide a attribuer des roles aux classes et le code qui en decoule est plus simple à comprendre. Et ca peut aussi servir a documenter .

[Gluups]

Il m'est arrivé de suivre le cheminement inverse.
A la relecture, je dois préciser que je veux dire inverse de ce que décrit Sara, et que je suis sur la même ligne que Lucas, ci-dessus.

J'ai été appelé pour améliorer le fonctionnement d'un code, j'ai commencé par passer trois jours à comprendre comment ça fonctionne, en me disant "voyons voir, comment ça marche ce truc, et qu'est-ce que ça doit faire ?"

Et c'est une fois que j'ai décortiqué tout ça que j'ai compris que la personne qui avait codé ça n'avait pas connaissance de la notion de fonction, et pour cette raison faisait des goto systématiquement vers le même point en faisant ensuite des tests sur un compteur.

Le seul contexte où je me vois coder comme ça est en prévision de confier le programme à "obfuscateur", pour avoir le maximum de certitude (vous noterez que je n'ai pas dit une certitude absolue) que personne sur terre, même pas moi, n'ait une chance de comprendre comment fonctionne ce truc en voyant le résultat de la décompilation -il est vrai que dans ce cas je pousserais vraisemblablement le bouchon plus loin.

Le fait est qu'une fois le code réécrit avec dix lignes au lieu de cent dans le module principal, et en appelant des fonctions aux noms explicites, l'utilisatrice était capable de modifier le résultat à la demande en fonction des évolutions des règles métier.

Bon alors ce n'est pas pour gonfler les chevilles : j'ai appris, lui pas.

[Gluups]

Au demeurant, je dois confesser qu'il m'est arrivé, par surmenage, de faire du mauvais boulot, de ne pas avoir le temps d'écrire en tête de chaque module les infos standard telles que qui qu'a fait ça, quand, pour quoi faire ...
Les règles étaient bonnes, mais je ne les ai pas appliquées, alors le résultat était mauvais.
Peut-être suis-je mal placé pour demander si le stress induit par le client était ou pas du bon boulot, et permettait ou pas de prendre le temps de sortir un code propre et bien commenté.

[el_slapper]

Un bon code est un code qui est comprehensible et maintenable par un tiers.

Si des ecarts sont fait ou le code est trop complexe, trois mots : commenter, commenter, commenter !

Si la maintenance ne peut pas etre faite par un tiers : réécriture.

Normalement, un semblant d'architecture doit preceder le code meme pour les petits projets : le fait de realiser un petit diagramme de sequence aide a attribuer des roles aux classes et le code qui en decoule est plus simple à comprendre. Et ca peut aussi servir a documenter .

Pas totalement d'accord. Le commentaire abondant ne doit pas masquer l'illisibilité du code. Le commentaire doit servir, à mon sens, à expliquer le "quoi", pas le comment.
*Si j'ai un pavé qui me dit "lecture des données client" et que je cherche un bug sur la date paramètre, je sais que je peux sauter. C'est un commentaire utile.
*Si le pavé me dit aussi "Appel de la base X"(juste avant un call X), "traitement du client non trouvé" (avant un IF X-CLIENT-NON-TROUVE), "remplissage du type CLIENT" (avant d'alimenter la donnée TYPE-CLIENT), c'est du bruit.

Et si le code ne me permet pas de déterminer que j'alimente le type client, c'est qu'il est mal écrit. ça n'est pas au commentaire de se substituer. C'est au code d'être lisible. Seuls des cas rarissimes peuvent justifier de décrire le "comment" dans un commentaire, généralement quand on a pas trouvé de moyen "propre" de faire(3 fois en 10 ans en ce qui me concerne). C'est un dernier recours, pas un systématique.

[mlezzoum]

Un développeur est :
soit chevronné - professionnel
soit initié
soit débutant

Etre chevronné professionnel et porter un jugement de valeur sur un développeur
débutant c'est une remise en cause du chevronné lui même.

Etre débutant et porter un avis négatif sur le code d'un chevronné, c'est un long parcours qui lui reste à faire le débutant, surement il changera de métier au cours de route.

Etre initié c'est regarder au dessus le chevronné avec un respect de l’élève qui apprend, et présenter un sagesse en baissant le regard pour voir les premiers pas du débutant.

Le secret de l'expert est de garder le silence et aider les autres et par modestie l'expert est désigné par la troisième personne du singulier.

que delphi soit avec vous. ( mes respects pour delphiprog au passage)

[akiniva]

Personnellement non. Je me dis toujours qu'un code peut-toujours être améliorer mais le code parfait n'existe pas, et puis il y a tellement de manière de coder qu'on ne peut être objectif en regardant un code éditer d'une manière différente !

[fredop]

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

Si vous travaillez sur un projet avec plusieurs personnes, je ne connais que deux solutions :
1-vous surveillez votre code en surveillant à chaque commit contre :
a-les modifications des autres
b-vos propres modifications! (effet de bord...)
2-vous designer des tests unitaires qui agissent comme un contrat de vos spécifications (le bouclier de SHuryu pour les intimes ) lancés automatiquement à chaque build. Le 1er qui casse le contrat à le droit à:
a-un email l'avertissant
b-un message jabber avec Build Failed (merci hudson!) au méchant et à tous les autres de l'équipe si nécessaire

Sinon vos faites comme de nombreuses personnes (ingénieur informatique compris) qui trouve que cela
- ne sert à rien les tests automatisés(normal au début le projet est tout simple)
- les tests c'est pas pour les super codeurs que vous êtes
.. jusqu'au jour où soit:
1-une grosse refonte est demandé et vous craignez de casser toucher du code d'un autre (qui n'est plus là bien sur) et craignez le syndrome de la patate chaude (si !! vous savez la fameuse règle implicite qui dit que "quiconque touche et commit un code, ce dernier devient le sien")
2- un bug est trouvé en prod. 3mois plus tard et qu'il faut 2 jours pour le débugger car aucun test n'a été fait pour bloquer la fonctionnalité et que cela aurait pu être trouvé avant en 10 minutes.

Et là la MOA tape sur la table, le chef de projet aussi & là il décide qu'il faudrait des tests unitaires mais le projet est devenu une hydre (chaque bug trouvé en révèle un autre) et certains auteurs du code ont disparu avec les spécifications dans leurs têtes (normal la documentation fonctionnelle ça ne sert à rien pensiez vous au début).

Alors a chaque itération vous avez le droit à une semaine de tests manuels ( Super vous refaites parfois les mêmes tests à chaque livraison, bonjour l'ennui !)

Ensuite bonne chance pour savoir qui a fait le bug :
-si la personne est un brin bourrin, elle va accusé l'auteur du code alors que ce n'est pas forcément vrai.


Et du haut de ma faible expérience, je ne vous dis pas le nombre de fois que
j'ai évité que quelqu'un brise mon code. Je ne compte plus. Et je défies quiconque de lancer environ 1200 tests manuels tous les jours (nombre moyen de tests automatiques lancés chaque jour sur un projet d'un 6 mois) sauf si vous avez une armée de testeurs en inde...


Par ailleurs, je recommande à tous la lecture du livre "clean code" appelé en français "coder proprement". Il est parfois extrémiste mais c'est l'un de ces livres qui sera toujours d'actualité même dans 10 ans sur l'art de la poésie technologique (comprenez la programmation)

[bifur]

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

[mayeulak]

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

[smoufid]

bonjour,
il faut etre humble et accepter le travail des autres.

[duboisa]

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.

[atc666]

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

[ymoreau]

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).

[Klaim]

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.

[Paul TOTH]

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.

[SirDarken]

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.