Commentaires sur : Jouez les Docteurs Love, apprenez à nettoyer du vieux code

Par : Blog Excilys » Refactoring par la pratique

Blog Excilys » Refactoring par la pratique — Tue, 03 Aug 2010 13:44:43 +0000

[...] un projet poubelle qu’il ne faut rien faire, au contraire ! Pensez juste à prendre des radiographies du patient [...]

Par : Touilleur-express

Touilleur-express — Mon, 02 Aug 2010 16:22:52 +0000

Touilleur-express…

[...] something about touilleur-express[...]…

Par : Sonar » Sonar in the news

Sonar » Sonar in the news — Mon, 02 Aug 2010 14:41:06 +0000

[...] Jouez les Docteurs Love, apprenez à nettoyer du vieux code By Le Touilleur Express, 28 July 2010 La vie d’un développeur ce n’est pas toujours de travailler à la création d’une nouvelle application. Au contraire nous serons souvent amené à faire ce que j’appelle de l’Archéologie. Cela veut dire entrer dans du code écrit il y a quelques années, être capable de faire fonctionner une vieille application, et surtout, être capable de la moderniser sans l’abimer. J’ai regroupé quelques outils et quelques pratiques apprises ces dernières années, mais n’hésitez pas à compléter. [...]

Par : Revue de presse, mois de juillet - Espace de fouille

Revue de presse, mois de juillet - Espace de fouille — Mon, 02 Aug 2010 09:20:41 +0000

[...] Jouez les Docteurs Love, apprenez à nettoyer du vieux code [...]

Par : fabszn

fabszn — Thu, 29 Jul 2010 09:52:15 +0000

Hello,

@Oaz : c’est une des principales difficultés que j’ai rencontrée dans mon équipe;concernant : « Ce sont des régles de bon sens mais il ne faut pas sous-estimer le principal frein à leur mise en place : le collectif
Ces règles ne peuvent fonctionner que si l’ensemble des développeurs amenés à toucher au code acceptent de jouer le jeu. Et ça c’est parfois plus dur à obtenir qu’un budget… »

Par : Oaz

Oaz — Wed, 28 Jul 2010 23:29:36 +0000

@Yannick G.
Ce qu’il y a d’extraordinaire avec le métier du développement logiciel, c’est que le budget est principalement une décision venant des développeurs eux-mêmes, du temps qu’ils décident, en leur ame et conscience, à allouer à telle ou telle activité.
Ce problème de budget, c’est un peu comme les éléphants de Ken Schwaber (*) : des personnes prennent des décisions qui n’ont pas de sens pour un observateur extérieur -par exemple modifier du code sans avoir pris le temps d’y mettre tous les tests qu’il fallait- parce que de mystérieuses forces les y conduisent.

(*) http://kenschwaber.wordpress.com/2010/07/27/the-elephant-in-the-room/

@l’auteur
Ce sont des régles de bon sens mais il ne faut pas sous-estimer le principal frein à leur mise en place : le collectif
Ces règles ne peuvent fonctionner que si l’ensemble des développeurs amenés à toucher au code acceptent de jouer le jeu. Et ça c’est parfois plus dur à obtenir qu’un budget…

Par : fabszn

fabszn — Wed, 28 Jul 2010 13:40:18 +0000

Hello,

Article très intéressant!

Dans les choses pas cher qui améliore considérablement la lisibilité du code et qui permet un refactoring dans de meilleurs conditions :
Le renommage des variables, méthodes, etc. Avec les outils de refactoring proposés par les IDEs actuels.

Le risque est quasi nul et la valeur ajoutée est énorme.

Par : Benoît Courtine

Benoît Courtine — Wed, 28 Jul 2010 12:25:28 +0000

Excellent article, comme d’habitude. J’aime beaucoup la comparaison avec la médecine.

J’ai déjà mis en place ce genre de pratique dans nos développements. En ce qui concerne l’outillage (Hudson, Sonar, etc.), d’expérience, ça plait beaucoup à la hiérarchie… tant que le coût des licences est nul ! Par contre, pour ce qui est des produits propriétaires (yourKit que tu cites… mais je pense également par exemple à SonarJ pour le contrôle de l’architecture), c’est une autre paire de manches.

Par : fsarradin

fsarradin — Wed, 28 Jul 2010 11:51:27 +0000

@Nicolas @hgomez: C’est en lisant des réflexions comme les vôtres qu’on fini par se dire que le logiciel à plus à faire avec la propriété intellectuelle qu’avec le brevet.

Par : hgomez

hgomez — Wed, 28 Jul 2010 11:09:06 +0000

Moderniser sans abimer, retoucher sans détruire, la maintenance de code ancien s’apparente souvent à la restauration de pièces de musée. Pas que l’oeuvre soit rare ou de qualité, mais juste ancienne et délicate.

Pour avoir mis la main plus que souvent dans du code de 5 à 10 ans, je plussoie l’ami Nicolas quand il parle de respecter le travail des anciens et de remettre le développement dans le contexte ‘historique’.

Parce qu’il n’y avait pas le même niveau de JVM, de moteur, de framework de runtime, de test, parce que certaines contraintes techniques avaient été imposées, parce qu’à l’époque peut être on considérait que le Java ça allait bien pour faire de la page Web mais que le fonctionnel ou la richesse devait être ailleurs.

Au final, un vieux programme c’est une page ouverte sur le passé, et le connaitre c’est comprendre beaucoup de choses non écrites dans le programme ou les docs qui l’accompagnent