Un code en polyester lavé en machine à 90° avec de la poudre à lessive certifiée qui ne tue pas les poissons une fois déversée dans la mer.
Ah ? on parlait pas de ça ?
Tout a été dit
-Commenté mais pas paraphrasé
-Efficace mais facile à comprendre
Un code en polyester lavé en machine à 90° avec de la poudre à lessive certifiée qui ne tue pas les poissons une fois déversée dans la mer.
Ah ? on parlait pas de ça ?
Tout a été dit
-Commenté mais pas paraphrasé
-Efficace mais facile à comprendre
Un code propre est un code qui crée des bugs facile à débugger. Ca passe ?
Un code propre est un code qu'on n'est jamais tenté de modifier.
Idéalement un code propre serait exempt de bug
Si tu remplace le terme "modifier" par "réécrire", je suis d'accord...
Je pinaille sur le terme, mais une modification du code peut très bien survenir simplement parce que, le temps aidant, tu as eu l'occasion de te rendre compte de certaines faiblesses de conception et que tu as décidé (ou du) revoir une partie de celle-ci, alors qu'une réécriture sera plutôt due à l'impossibilité du lecteur de comprendre le raisonnement que l'auteur a pu suivre, rendant toute modification hasardeuse et potentiellement dangereuse
Dans le premier cas, c'est un risque inhérent au cycle de développement, dans le second cas, c'est effectivement le signal qu'un code n'est sans doute "pas propre".
Si tu modifie le terme réécriture par refactoring (refactorisation, remaniement ...) alors je serais encore plus d'accord
eh bien moi non
refactoring peut apparaître avec des changements de paradigmes...
réécriture est plus restreint, à mon sens, et ne comporte pas en tant que tel un changement de paradigme (mais sans doute des posibilités de changement de langage)..
M'enfin..
Où l'on voit bien que les termes étant flous, leur usage l'est tout autant..
Il y a là comme une contradiction, non ??
- Ou bien c'est précis, et il n'y a pas d'exception
- Ou bien c'est flou, et dans certains cas le sens n'est pas le même...
De même, dans combien de cas "refactoring" n'est pas utilisé pour du "legacy code" ??
Et quelle est ta définition d'un "legacy code" ??
Tu devrais lire 2-3 articles sur le refactoring avant de le critiquer, visiblement tu n'y connais rien. Tu peux commencer par là par exemple.
je ne connais peut-être (certainement) pas la théorie, mais j'ai déjà été sur 3 projets dans les dernières années où on m'a dit que l'on faisait du "refactoring"..
Alors je ne sais pas si tout le monde (probablement) utilise mal le mot, mais l'industrie et les Chefs de Projets et Directeurs Techniques que j'ai rencontré n'y connaissent rien alors...
Ce qui est vraisemblable, mais donc par conséquent n'enlève strictement rien au flou artistique...
Et tu n'as pas répondu à ma question par rapport à la définition de "legacy code" par rapport au reste...
Je maintiens le terme "modifier". Il semble utopique qu'un bout de code puisse paraître propre aux yeux de toutes les personnes qui auront à le lire, étant donné que la propreté du code est une notion subjective. Une application est bien plus facile à maintenir si on a jamais besoin de modifier le code qui existe déjà, mais seulement d'en ajouter.
A mon sens une bonne conception est avant tout une conception qui permet d'écrire une application où on aura uniquement besoin d'ajouter du code, et non d'en modifier.
Comment peut-on réécrire un code qu'on ne comprend pas ? Cette notion de réécriture ne me plaît guère. Elle suppose que la personne qui réécrit fera forcément plus propre que les auteurs précédents. Mais ce n'est pas le cas : elle fera plus propre à ses yeux. Peut-être que le prochain lecteur du code trouvera à son tour que le code est illisible et réécrira à son tour. On n'en finit plus. Chacun pense qu'il écrit du code plus propre que les autres.
La maintenabilité d'un code ne réside pas dans la façon dont il est écrit mais bien dans sa conception : une bonne conception et il n'y a pas besoin de modifier, juste d'ajouter.
Pour moi un code propre n'est pas forcement commenté. C'est un code qui suit un découpage logique et intelligent et qui s'y tiens.
Ben je ne suis pas d'accord non plus. Peut-être que je ne connais pas le terme "refactoring" moi non plus, mais pour moi, du refactoring c'est prendre un code et le transformer pour qu'il fasse exactement la même chose tout en l'écrivant différemment : Renommer une méthode (ou une variable), changer l'ordre de ses paramètres d'appels, factoriser du code qui se répète en le remplaçant par un appel à une seul et même méthode...
Bref, qu'en j'entends refactoring, il s'agit ni plus ni moins que de cosmétique. Tu ne remets jamais en cause l'algorithme ni la conception elle même.
Si ça va plus loin, je ne parles plus de "refactoring" mais de "rework". Ce qui n'est rien d'autre qu'un terme anglais pour dire "réécrire".
Or un code sale deviendra rarement propre en ne faisant qu'une succession de transformations équivalentes entre elles.
Le terme "réécrire" est très clair : Tu prends l'existant, tu le jettes à la poubelle et tu recommences comme s'il n'avait jamais existé. (celà dit, c'est vrai qu'un code peut être sale sans nécessité pour autant une réécriture complète)...
Malheureusement, la maintenance ne se résume pas à de la maintenance évolutive.Envoyé par I_believe_in_code
Il y a énormément de cas dans l'informatique ou tu dois modifier un code qui était parfaitement propre :
- Déjà un code peut être propre tout en étant bogué. Difficile de corriger le bogue sans le modifier...
- Ensuite, même si le code est parfait rien ne te dit que lorsque le client aura l'appli entre les mains, il ne te dira pas : "a mais non, ce n'est pas ce que je veux", ou encore "ben oui, c'est bien ce que j'ai demandé, mais en fait non, maintenant je me rends compte que j'avais besoin que ça fonctionne différemment", ou encore : "ben en fait, j'avais rien compris moi même avant de le demander, et maintenant que j'ai compris, ben va falloir modifier deux ou trois choses".
C'est très simple : Tu connais le projet, tu connais les spécifications. Tu sais que lorsque tu appelles cette méthode, elle doit réaliser ce calcul. Les tests te montre qu'elle calcule faux. Tu rentres dans le code pour la déboguer et lorsque tu vois l'usine à gaz totalement incompréhensible qui se trouve derrière alors que le problème était tout simple, tu te dit : J'aurais plus vite fait de tout réécrire plutôt que d'essayer de comprendre ce que le mec avant moi a voulu faire...Comment peut-on réécrire un code qu'on ne comprend pas ?
Là tu parle de correction de bug, qui implique parfois de refaire une portion non négligeable du code.C'est très simple : Tu connais le projet, tu connais les spécifications. Tu sais que lorsque tu appelles cette méthode, elle doit réaliser ce calcul. Les tests te montre qu'elle calcule faux. Tu rentres dans le code pour la déboguer et lorsque tu vois l'usine à gaz totalement incompréhensible qui se trouve derrière alors que le problème était tout simple, tu te dit : J'aurais plus vite fait de tout réécrire plutôt que d'essayer de comprendre ce que le mec avant moi a voulu faire...
dans le cadre du refactoring, si je ne me trompe pas, on parle de refaire un code qui marche afin de le rendre plus facilement maintenable et/ou plus efficace et/ou plus logique?
C'était ironique étant donné que sa vision est exacte...
Edit "presque exacte" puisque justement l'objectif est que la succession de transformation équivalente aboutisse à un code propre. Cela dit ça demande du temps, mais comme le dit Benwit, bien souvent le fait de renommer et de faire de l'extraction de méthode suffit déjà à y voir beaucoup plus clair.
Voilà une bonne définition d'un code déjà bien propreFranck SORIANO : Tu sais que lorsque tu appelles cette méthode, elle doit réaliser ce calcul.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager