Un sujet dont vous entendrez les ingénieurs discuter de temps en temps est la dette technique. A partir du nom, vous pouvez déjà deviner qu'il s'agit de quelque chose de non-désirée. A entendre les développeurs, n'importe quel logiciel qui est en production depuis quelques mois peut en avoir. Un logiciel qui est trop endettée ne peut survivre. Il devient instable, non-maintenable, et non-pertinant.
Mais qu'est-ce donc que la dette technique? Comment un logiciel contracte-t-il cette dette, et comment s'en débarrasser ? Où l'éviter autant que possible ?
Il y a de nombreux types différents de dette technique mais voici un exemple simple. Le code des logiciels est souvent organisé en méthodes ou fonctions qui mettent en oeuvre des fonctionnalités. Les applications simples peuvent avoir des centaines de méthodes. Un logiciel sophistiqué au niveau d'une entreprise peut contenir une centaine de milliers de méthodes. Supposons que vous ayez quelque part la méthode suivante:
public void DoSomethingInteresting(
string A,
string B,
string C)
{
// Method body: Implementation goes here
}
Les parties du logiciel---les autres méthodes---qui veulent “do something interesting” vont appeler ou invoquer cette méthode pour le faire. Pour faire cela, cette méthode a besoin de trois entrées ou paramètres: string A, string B et string C. Le code qui invoque la méthode va regarder quelque chose de similaire à cela:
DoSomethingInteresting(A, B, C);
Il peut y avoir entre une et une centaine ou plus de ces utilisations dans le code du logiciel. Il est peut être utilisé par l'interface utilisateur, en méthodes API externe, dans un traitement d'import, ou pour générer des états.
Supposons que quelqu'un décide de modifier le logiciel et que le comportement qui était contrôlé par le troisième paramètre---string C---dépend maintenant uniquement d'un paramètre de configuration du système. En d'autres termes, l'implémentation ou le corps de la méthode de DoSomethingInteresting peut juste regarder cette option de configuration. Il ne dépend plus de string C de quelque manière que ce soit. Que se passe-t-il si notre développeur n'enlève pas string C de la déclaration de la méthode bien que ce ne soit plus référencé dans l'implémentation? Est-ce que le code se compile toujours? Bien sûr. Est-ce que les applications fonctionnent toujours normalement? Absolument. En fait, il n'y a aucun moyen pour que l'utilisateur, ou le département QA puisse dire que quelque chose n'est pas correcte.
Mais le logiciel a maintenant un peu de dette technique.
- La déclaration de DoSometingInteresting est plus complexe que ce qu'elle doit être. Le prochain développeur qui regardera DoSomethingInteresting doit passer du temps à comprendre le paramètre C jusqu'à ce qu'il réalise qu'il ne fait rien. Donc nous avons touché à la maintenabilité du code.
- Tout ce qui dans le code invoque DoSomethingInteresting doit quand même fournir une valeur pour le paramètre C. Le prochain développeur pourrait essayer d'implémenter une nouvelle fonctionnalité en modifiant le code pour y passer quelque chose de différent; toutefois, cela n'aura aucun effet. Nous avons alors facilité l'introduction d'un bug.
- Beaucoup des codes existants qui appellent DoSomethingInteresting peuvent alors faire un travail supplémentaire non nécessaire pour fournir le paramètre C, comme lire des données dans une base de données. Le logiciel tournerait alors plus lentement qu'il ne le pourrait.
Même si la modification initiale fonctionne correctement, cette petite dette technique peut poser des problèmes un jour ou l'autre. C'est juste un petit paramètre non utilisé sur une petite méthode parmi des millions de lignes de code. Il est facile de voir comment les fins non abouties peuvent s'ajouter aux problèmes importants.
Parfois vous vous soumettez à des dettes financières pour une bonne raison: aller à l'université, acheter une maison. C'est une décision stratégique et le même chose peut être faite avec une dette technique. A court terme, vous pouvez poursuivre pour aller plus vite et terminer un projet important plus rapidement. Tandis que cette approche pourrait s'appeler "prendre des raccourcis", c'est parfois la bonne chose à faire tant que vous avez un plan pour payer en retour cette dette en un temps raisonnable. De même, comme les dettes financières, les dettes techniques peuvent s'accumuler, et vient en général avec des intérêts. Plus vous en avez dans votre code, plus c'est difficile de le comprendre et de faire les changements. Cela devient plus facile d'introduire des bugs et et bien plus difficile de les trouver et de les corriger.
Donc pour en revenir à notre exemple précédent, qu'aurait dû faire le développeur? Puisque l'implémentation de DoSomethingInteresting n'a plus besoin de string C, le développeur doit changer la déclaration de l'expression pour la clarifier:
public void DoSomethingInteresting(
string A,
string B)
{
// Method body: Implementation goes here
}
Le développeur doit également ajuster tout code qui invoque cette méthode pour l'appeller sans string C, et nettoyer tout code supplémentaire qui était nécessaire pour trouver ou produire string C.
DoSomethingInteresting(A, B);
Pourquoi notre développeur ne le ferait pas? Cela peut être aussi simple que de ne pas l'avoir remarqué, ou peut être que le développeur a pensé que cela prendrait trop de temps.
Heureusement, il y a des outils qui résolvent ces deux problèmes de manière efficace. Dans AdvantageCS, nous utilisons de nombreux outils comme ReSharper, une extension d'analyse de code de Microsoft Visual Studio. ReSharper est constamment en train d'analyser notre code en arrière-plan pendant qu'il travaille. Les développeurs peuvent obtenir des informations sur de nombreux problèmes de qualité de codes en temps réel. Nous utilisons aussi Microsoft Code Analysis Build, des révisions de codes, et des tests automatisés tous destinés à éviter le plus de dette technique possible. Ces outils automatise aussi largement le traitement qui nettoie toute dette existante, comme enlever un paramètre non utilisé d'une méthode et bien plus encore.
Cette vigilance peut sembler parfois un peu académique. Après tout, le logiciel pourrait fonctionner même s'il y a beaucoup de méthodes avec des paramètres supplémentaires. Mais cette attention au détail est une pratique essentielle pour créer un logiciel qui dure. Minimiser et gérer la dette technique chez AdvantageCS nous a aidé à founir un logiciel leader du secteur pour les dernières 35 années et va nous permettre de continuer à fournir un logiciel de quailité, personnalisable et pertinent pour les années à venir.