Dans l’article précédent, je te parlais de ce qu’est une architecture logicielle et de la nécessité de la faire émerger.
Pour y arriver, il faut manipuler son code comme de la pâte à modeler ; car avoir une conception qui tape dans le mille du premier coup est proche de l’impossible.
Et puis de toute façon, c’est un fait, le besoin change !
Pour répondre à ces nouveaux besoins, il faut modifier le code.
Qui dit le modifier dit potentiellement introduire des bugs, casser des choses.
Et là , forcément, la peur te gagne. Comment limiter ce risque ? Comment éviter de casser, de créer des bugs ?
Je ne vais pas te le cacher, il n’y a pas 36 solutions, il faut… tester !
Dans cet article, je vais parler de plusieurs stratégies pour à la fois prévenir l’apparition de bugs mais aussi permettre de faire émerger une architecture saine et évolutive.
Pour ne plus avoir peur de casser des choses en modifiant le code.
L’objectif est toujours d’avoir la conception la plus optimale possible pour répondre au besoin présent ; sans sur-ingénierie (pas de code “au cas où”) et sans sous-ingénierie (pas de duplication partout).
Une conception aux petits oignons pour apporter de la valeur MAINTENANT.
Voici la liste des stratégies que je vais développer :
- tester manuellement,
- laisser le compilateur tester pour moi,
- automatiser mes tests (tu apprendras aussi pourquoi TDD rend plus efficace et permet de gagner du temps !).
Top comments (0)