Faire le ménage dans le code : mettre le code mort à la poubelle ou le garder au cas où ?

Une question d'un développeur:
La prochaine itération va comporter un bon nombre de tâches techniques et nous avons pensé « faire le ménage » dans notre code, mais que faire du code mort ? Faut-il supprimer les sections inutilisées ... en partant du principe qu’elles polluent les classes ... ou bien les conserver si un jour elles venaient à resservir ?" Ma réponse...

Mon avis: supprimer sans état d'âme le code dit "mort", à partir du moment ou il a été committer au moins une fois dans subversion.

Il peut être envisageable de noter le numéro de révision ou la date ou de créer un tag dans subversion avant tout nettoyage de printemps. Ce qui vous permettra de retrouver plus facilement/rapidement le code ensuite.

Rien ne vous empêche de garder une version en local du trunk à la révision actuelle, en plus du trunk sur lequel vous travaillé. Ce qui vous permettra d'avoir directement sous la main le code source "legacy" qui pourrait être de nouveau nécessaire.

Ne laissez pas de code mort dans le trunk, "la mort amène la gangrène" ;)

Si vous pensez que les développements réalisés mettent en oeuvre un concept qui pourra être réutilisable, par contre le code lui non, alors écrivez un article wiki pour décrire ce pattern / concept / technique, ca vous prendra 15-30 minutes et ce sera facilement accessible pour tout le monde.

N'oubliez pas qu'un de vos objectifs utopique est d'avoir le moins possible de lignes de code, et qu'elles soient le plus simple possible.

Ma maxime préférée : "L'excellence attire l'excellence" : si votre code est propre, enviables, beau, clean, smart (whatever you want), les nouveaux développements auront beaucoup plus de chances de l'être.

Et vous qu'auriez vous répondu ?

Commentaires

1. Le lundi, septembre 14 2009, 12:52 par Gab

"Le travail fait n'est jamais perdu", dixit un collègue ;)
Tu dégage le code, mais les idées que tu as mis en oeuvre pour l'écrire reste d'une manière ou d'une autre dans ta tête.

2. Le mardi, septembre 15 2009, 14:35 par Martin

Exactement la même chose. Votre réponse est parfaite. On trouve si souvent des méthode commentées dans des classes sans savoir qui les a écrites, qui les a commentées et pourquoi... La gestion des version est là pour cela.

Quand au wiki c'est effectivement un point intéressant pour peu que l'on en ai un sous la main.

3. Le samedi, septembre 19 2009, 10:52 par Raph

On dispose de solutions pour garder des traces de changements (svn par exemple), par contre j'ai toujours pas trouvé de solution efficace permettant de "se souvenir" de ce qui a été fait.

Vous est-il déjà arrivé de récupérer un vieux code dont vous n'aviez la connaissance ni au moment de son écriture, ni du nettoyage ?

Je suis persuadé que le seul cas où ça se produit c'est le coup du collègue qui dit "ya machin qui avait codé quelque chose de similaire, regarde le dépot".

4. Le samedi, septembre 19 2009, 10:59 par Olivier Hoareau

@Raph: bonne remarque, effectivement cela arrive régulièrement de commencer à développer une snippet pour nos propres besoins et de se rendre compte que quelque chose de similaire a déjà été développé dans l'équipe (par le passé, ou ... en parallèle !). Pour tenter d'endiguer ce problème je propose en règle général un ensemble de pratiques simples à mes développeurs: 1/ regarder si un "service" (par exemple technique) n'existe pas déjà dans l'API projet, 2/ ne jamais copier / coller mais plutot déplacer du code à un endroit central et l'utiliser à plusieurs endroits, 3/ toujours développer la solution la plus simple possible pour répondre au besoin du moment, entres autres.

Eclipse et Zend Studio propose des "Code Gallery", je pense que c'est aussi une piste pour retrouver du code déjà développer en ayant une démarche "search first, code after".

Commentaires récents

Gab:
"Le travail fait n'est jamais perdu", dixit un collègue ;)
Tu dégage le code, mais les idées que tu as mis en oeuvre pour l'écrire reste d'une manière ou d'une autre dans ta tête.

Martin:
Exactement la même chose. Votre réponse est parfaite. On trouve si souvent des méthode commentées dans des classes sans savoir qui les a écrites, qui les a commentées et pourquoi... La gestion des version est là pour cela.

Quand au wiki c'est effectivement un point intéressant pour peu que l'on en ai un sous la main.

Raph:
On dispose de solutions pour garder des traces de changements (svn par exemple), par contre j'ai toujours pas trouvé de solution efficace permettant de "se souvenir" de ce qui a été fait.

Vous est-il déjà arrivé de récupérer un vieux code dont vous n'aviez la connaissance ni au moment de son écriture, ni du nettoyage ?

Je suis persuadé que le seul cas où ça se produit c'est le coup du collègue qui dit "ya machin qui avait codé quelque chose de similaire, regarde le dépot".

Olivier Hoareau:
@Raph: bonne remarque, effectivement cela arrive régulièrement de commencer à développer une snippet pour nos propres besoins et de se rendre compte que quelque chose de similaire a déjà été développé dans l'équipe (par le passé, ou ... en parallèle !). Pour tenter d'endiguer ce problème je propose en règle général un ensemble de pratiques simples à mes développeurs: 1/ regarder si un "service" (par exemple technique) n'existe pas déjà dans l'API projet, 2/ ne jamais copier / coller mais plutot déplacer du code à un endroit central et l'utiliser à plusieurs endroits, 3/ toujours développer la solution la plus simple possible pour répondre au besoin du moment, entres autres.

Eclipse et Zend Studio propose des "Code Gallery", je pense que c'est aussi une piste pour retrouver du code déjà développer en ayant une démarche "search first, code after".

PHPPRO