Mes recommandations pour maîtriser la dette technique au quotidien
Avant propos
Ce document est le résultat de mes divers expériences, il va sans doute évoluer, sera remis en cause dans les prochaines années.
Allégorie d’une partie de Tetris
Tout d’abord, j’invite à lire cet excellent article « La dette technique est comme une partie de Tetris. Tout code possède de la dette technique. C’est parfaitement normal. Vous pouvez continuer à jouer à Tetris même avec quelques trous. ».
Règles de bases
Voici les règles que je suis pour garder la maitrise de mes projets :
- tout développeur doit à tout moment pouvoir installer, exécuter et utiliser localement un projet.
Comment ?- documenter les instructions d’installation et d’exécution, faire tester par plusieurs personnes
- quand un projet dépend d’infrastructures difficiles ou impossibler à installer, essayer de créer des composants qui simulent ces dépendances
- faire des efforts pour avoir des données pour les tests (fixture…) et/ou de démo (sample data)
- tout développeur (autorisé) doit pouvoir à tout moment déployer le projet (from scratch et de manière incrémentale).
Comment ?- documenter la procédure de déploiement, faire tester par plusieurs personnes
- utiliser un outil d’Infrastructure as Code
- utiliser un outil de migration de modèle de données (SQL…)
- tout développeur doit toujours pouvoir tester localement un projet (manuellement ou automatiquement).
Comment ?- documenter les instructions de test, faire tester par plusieurs personnes
- mettre à disposition des fixture et/ou des données de démo (sample data)
Au quotidien
Au quotidien, quand j’interviens sur un projet et que :
- je vois quelque chose d’améliorable
- je vois quelque chose difficile à comprendre
- je vois du code inconsistent avec le reste du projet
- j’ai beaucoup de difficulté à réaliser une tâche à cause de l’architecture actuelle du projet
alors j’ai deux possibilités :
- si l’amélioration est rapide alors je l’exécute tout de suite dans une Merge Request
- ou alors je crée une Issue avec le label « Technical Debt » pour ne pas tondre un Yak!
Quand je tombe plusieurs fois sur quelque chose qui me fait perdre du temps, un élément de dette technique : mettre un 👍 (pour signifier « moi aussi j’ai ce problème ») et peut être un commentaire supplémentaire sur l’issue de cette dette technique.
Quand je suis bloqué sur une issue, en attente d’information ou de review de code… alors c’est peut être le bon moment pour avancer un peu sur un ticket de bug ou de dette technique.
Si un élément de dette technique ralenti fortement le développement, alors l’intégrer dans un sprint.
Qu’est-ce qui n’est pas pour moi de la dette technique ?
Je ne considère pas être de la dette technique les éléments suivants :
- le choix du langage de programmation
- le choix du framework
- un choix d’architecture
- des bugs
Qu’est-ce que je considère être de la dette technique ?
Tout ce qui m’empêche de travailler correctement sur un projet, par exemple :
- je n’arrive pas à installer l’environnement de developement du projet de manière autonome
- je n’arrive pas à utiliser (« jouer avec ») le projet localement
- je n’arrive pas à tester (manuellement ou non) une fonctionnalité du projet en dehors de son environnement de production