TL:DR;

Il est toujours plus facile de rajouter du code quand il y en a peu. Je suis pourtant parfois tenté de croire que certaines fonctions vont servir à nouveau un jour, mais ce jour là, le besoin aura changé et je préférerai probablement recommencer. Faire plus joli et plus en adéquation avec le besoin du moment. J’ai décidé de jeter régulièrement et sans hésiter.

Le code historique

Q : “A quoi sert cette colonne sur la table `users` ?”

R : “Elle est là pour des raisons historiques, on ne s’en sert plus vraiment”

Quels sont les apports d’un morceau de code, d’une colonne dans une table ou d’une propriété d’une classe qui n’est plus utilisée ? Plus de texte à lire, souvent un peu de confusion (“ce n’est pas cette méthode qu’il faut utiliser mais l’autre”), une perte de contrôle du produit dans le pire des cas. Il m’a semblé qu’il était assez rare de faire des algorithmes complexes (en dehors de certaines parties du coeur de l’application), il n’est pas difficile de refaire une portion de code. Il me semble donc préférable de jeter rapidement du code quitte à le refaire plus tard.

La simplicité d’un projet comme gage de qualité

Peu de lignes de codes, un nombre limité de classes et de méthodes pour une application ou un service (en dehors de leurs dépendances) permet d’assurer plus simplement la qualité. Moins de tests unitaires et fonctionnels à rédiger, et surtout moins de hooks pour garantir le fonctionnement des différents cas. Un projet est généralement plus lisible dans ses premiers mois que dans les suivants, ainsi jeter souvent me permet de préserver la simplicité initiale.

Réutilisation ? Jamais.

Réutiliser ou relire du vieux du code est une expérience désagréable. Limitons son existence par sa destruction pour ne pas ressentir le rejet, la honte ou le dégout en revoyant un code que nous pensions réutiliser un jour (l’accumulation de code pouvant être perçu comme une pathologie par les nouveaux venus sur un projet)

Le code commenté

// if ( something() )

// doSomethingElse();

La signification d’un code commenté est souvent mystérieuse. S’agit-il de code qui ne marche pas vraiment ou d’un joli algorithme qui a marché un jour ? D’un test qu’on a peur d’oublier ou d’une méthode qu’on réactivera si l’autre ne marche pas ? Si c’est pour le retrouver git pourra m’aider, s’il s’agit de documentation une explication sera probablement plus utile. A jeter, donc.

http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation

Ce qui ne sert à rien ne sert à rien

Ce qui est valable pour l’UX l’est aussi pour le code. Pour ne pas avoir de code mort, le mieux est de ne développer que ce qui est utilisé. Je suis souvent tenté de vouloir concevoir une structure complexe répondant aux potentiels cas futurs, alors que le besoin actuel est simple et qu’une re-factorisation s’imposera de toute façon lorsque des nouveaux besoins apparaitront. Faire peu de code, c’est jeter de manière préventive.

Merci à Gildas pour la punchline.