Discussion :

[_skip]

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

[ipingu]

Un code propre est un code qui crée des bugs facile à débugger. Ca passe ?

[I_believe_in_code]

Un code propre est un code qu'on n'est jamais tenté de modifier.

[koala01]

Un code propre est un code qui crée des bugs facile à débugger. Ca passe ?

Idéalement un code propre serait exempt de bug

Un code propre est un code qu'on n'est jamais tenté de modifier.

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

[rad_hass]

Si tu modifie le terme réécriture par refactoring (refactorisation, remaniement ...) alors je serais encore plus d'accord

[souviron34]

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

[Furikawari]

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

Refactoring n'est pas un terme flou (bien au contraire), et en général il ne s'accompagne pas de changement de paradigme (je dis en général car dans le cas de legacy code ça pourrait se discuter).

[souviron34]

Refactoring n'est pas un terme flou (bien au contraire), et en général il ne s'accompagne pas de changement de paradigme (je dis en général car dans le cas de legacy code ça pourrait se discuter).

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" ??

[Furikawari]

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.

[souviron34]

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

[Furikawari]

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

C'est vrais que les chefs de projets détiennent la vérité absolue et sont représentatifs du travail des développeurs...

S'il te manque des définitions => google est ton ami.

[I_believe_in_code]

Idéalement un code propre serait exempt de bug

Si tu remplace le terme "modifier" par "réécrire", je suis d'accord...

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.

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,

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.

alors qu'une réécriture sera plutôt due à l'impossibilité du lecteur de comprendre le raisonnement que l'auteur a pu suivre

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.

[apophyss]

Un code propre pour moi c'est aussi un code 'stupide'.
En tout cas très simple, facilement lisible, facilement compréhensible
et facilement deboguable par quelqu'un d'autre.

Donc éviter MVC...

[el_pedro]

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.

[Franck SORIANO]

Si tu modifie le terme réécriture par refactoring (refactorisation, remaniement ...) alors je serais encore plus d'accord

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

Une application est bien plus facile à maintenir si on a jamais besoin de modifier le code qui existe déjà

Malheureusement, la maintenance ne se résume pas à de la maintenance évolutive.
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".

Comment peut-on réécrire un code qu'on ne comprend pas ?

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

[benwit]

Or un code sale deviendra rarement propre en ne faisant qu'une succession de transformations équivalentes entre elles.

Tu as raison de dire rarement car si tout code sale ne peut pas être lavé en machine, euh ... refactorer, parfois, un bon renommage des paramètres, des méthodes peut le rendre plus propre

[souviron34]

Peut-être que je ne connais pas le terme "refactoring" moi non plus

Merci je me sens moins seul

[jabbounet]

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

Là tu parle de correction de bug, qui implique parfois de refaire une portion non négligeable du code.

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?

[Furikawari]

Merci je me sens moins seul

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.

[Nebulix]

Franck SORIANO : Tu sais que lorsque tu appelles cette méthode, elle doit réaliser ce calcul.

Voilà une bonne définition d'un code déjà bien propre