Êtes-vous un archéologue logiciel ?

J’appelle archéologue logiciel le développeur qui passe une grande partie de son temps à fouiller le code pour trouver un bug ou l’endroit parfait où ajouter une fonctionnalité.

Dans bien des cas, on passe plus de temps à chercher où intervenir qu’à coder réellement. Dans de grands systèmes complexes, parfois mal conçus, cette tâche devient fastidieuse et démotivante. On s’ennuie, on perd du temps, et la vélocité de l’équipe chute.

Quelques pistes pour creuser moins

• Garder une documentation claire, organisée et à jour.
• Ajouter des commentaires pertinents — sans excès.
• Réduire la dette technique dès que possible.
• Prendre le temps de faire de bonnes revues de code.
• Employer la même terminologie que les experts métiers dans le code (voir le Domain Driven Design).
• Stabiliser l’équipe et limiter le roulement.
• S’appuyer sur des référents qui connaissent à la fois le fonctionnel et la technique.
• Supprimer les fonctionnalités inutiles : elles finissent toujours par semer la confusion.
• Favoriser les échanges entre collègues, pour éviter qu’une personne tourne en rond trop longtemps.
• Écrire du code qui introduit le moins de bugs possible. Le TDD aide beaucoup : les tests servent de documentation et se rejouent à volonté.

Moins de temps passé à fouiller, c’est plus de temps pour créer. Et une équipe nettement plus motivée.