Gestion de régression

Question

Je suis un codeur impulsif par nature et j'ai commencé à apprendre la vertu de la patience à la dure dans la programmation. L'un des domaines que j'ai le plus mal est quand je modifie le code existant. Si je n'ai pas tous les détails devant moi, je manque invariablement certaines pistes qui mènent parfois à la régression. Je suis d'accord dans le codage, mais sous-estimé la maintenance du code jusqu'à ce que je lis "Patterns de mise en œuvre". Donc, ma question est de savoir si vous maintenez le code existant, comment couvrez-vous toutes les bases et assurez-vous de ne pas laisser de nids de poule derrière vous? Quelles sont les stratégies que vous utilisez lorsque vous ne savez pas où le code peut se casser?

Answer 1

Tests unitaires, en bref. Vous avez besoin d'une couverture de test pour vous assurer que lorsque vous apportez des modifications, vous pouvez réexécuter les tests et vous assurer que vous n'avez rien brisé.

Si vous avez une intégration continue, alors cela apparaîtra au fur et à mesure de l'enregistrement. Je voudrais vérifier tôt/souvent pour vous assurer que vos changements sont petits, et que vous pouvez facilement suivre les causes de bogues.

La céphalée est l'adaptation de tests unitaires à un cadre déjà existant. Vous devrez probablement réorganiser une partie de la bibliothèque existante afin de permettre dependency injection et mocking. Malheureusement, le simple fait de faire ces changements n'est pas sans risques, et tout ceci conduit à écrire les tests le plus tôt possible (et à concevoir votre code pour qu'il soit facile à tester).

Answer 2

Si vous pouvez trouver des cas de bords, vous pouvez écrire des tests unitaires. Ensuite, après les modifications, vous pouvez vérifier que vos tests sont toujours valides.

Ce n'est pas infaillible, mais c'est mieux que rien!

Answer 3

Test unitaire, en un mot. L'un des avantages de l'écriture de tests unitaires est qu'il peut rendre le refactoring/les changements de code ultérieurs plus sûrs et donner plus de confiance que ces changements n'ont rien brisé. Reliez ceci à un environnement d'intégration continue, où le dernier code est périodiquement retiré du contrôle de la source, construit et ensuite tous les tests unitaires s'exécutent, et vous obtenez une rétroaction assez rapide de manière automatique si des changements de code rompent la construire.