Est-ce que du « code propre » vaut toujours le temps investi, ou est-ce que « assez bon » est parfois acceptable ?

Question

Accepted Answer

**Cela dépend de la durée de vie du code et de son rayon d'impact.** Le code propre est très rentable pour le code qui dure et change ; « assez bon » est le bon choix pour le code jetable, prototype, ou rarement modifié. L'astuce est d'adapter votre investissement à la situation — en évitant à la fois la négligence et le sur-ingénierie.

## Le principe : adapter l'effort à la durée de vie du code

La qualité du code est un **investissement**, et comme tout investissement, son rendement dépend du temps et de l'exposition. Deux questions à se poser :

- **Combien de temps ce code vivra-t-il ?** Le code lu et modifié pendant des années mérite de la clarté ; un script unique ne le mérite pas.
- **Quel est le rayon d'impact ?** Un module central touché par beaucoup de personnes et dépendant de chemins critiques mérite de la prudence ; un coin isolé qui change rarement ne le mérite pas.

## Quand le code propre gagne clairement

- Code qui **change souvent** — la clarté est payante chaque fois que quelqu'un le lit ou l'édite.
- Code **partagé, central, ou longue durée** — le coût de la confusion se multiplie à travers les personnes et le temps.
- Tout ce où un **bogue est coûteux** — paiements, authentification, intégrité des données.

## Quand « assez bon » est le bon choix

- **Code jetable** — spikes, expériences, migrations uniques, un script que vous supprimerez demain.
- **Prototypes** destinés à valider une idée, pas à survivre.
- Code **rarement modifié, à faible risque** où le polissage apporte peu.

## Les deux modes d'échec

| Échec | Ressemble à | Coût |
|---|---|---|
| **Négligence** | envoyer du désordre dans du code qui vivra | changements futurs lents, bugs, érosion |
| **Sur-ingénierie** | sur-concevoir du code qui n'aura pas d'importance | temps gaspillé, abstraction prématurée |

Les deux sont du vrai gaspillage. « Assez bon » est un choix *délibéré, contextuel* — pas une excuse pour la négligence, et pas une licence pour polir indéfiniment.

## Pourquoi c'est important

Cette question sépare les ingénieurs qui appliquent la qualité **dogmatiquement** de ceux qui l'appliquent **économiquement**. Traiter le code propre comme une religion gaspille l'effort sur des jetables ; le traiter comme optionnel ronge les systèmes dont vous dépendez. Le jugement des ingénieurs seniors consiste à savoir *quel type de code vous tenez* et investir en conséquence — et être capable d'expliquer ce compromis est exactement le genre de pensée pragmatique que les équipes veulent voir.

Échec	Ressemble à	Coût
Négligence	envoyer du désordre dans du code qui vivra	changements futurs lents, bugs, érosion
Sur-ingénierie	sur-concevoir du code qui n'aura pas d'importance	temps gaspillé, abstraction prématurée