Maintenir le code proche de la panne

Question

Disons que vous êtes le programmeur chanceux qui a hérité d'un code proche de la pourriture du logiciel. Le logiciel pourri tel que défini dans Pragmatic Programmer est un code trop moche (dans ce cas, un code non réactualisé) il est comparé à une fenêtre cassée que personne ne veut réparer et qui peut endommager une maison et causer des criminels à prospérer. ville.

Mais c'est le même code que Joel Spolsky dans JoelOnSoftware valorise de telle façon qu'il contient des correctifs de valeur qui ont été débogués pendant toute sa durée de vie (qui peut sembler déstructurée et laide).

Comment est-ce que tu maintiens ça?

Answer 1

Jetez un oeil à Working Effectively with Legacy Code par Michael Feathers. Beaucoup de bons conseils là-bas.

Answer 2

Vous pouvez faire quelques petites choses:

• Refactor le code pour le rendre plus maintenable. Si le code est également utilisé pour le développement de fonctionnalités, le refactoring prend tout son sens.
• Si le code est ancien code et est touché uniquement pour les corrections de bugs alors je vous suggère de ne corriger que si nécessaire et lorsque cela est nécessaire.
• Souvent, la première impression que les gens obtiennent d'un tel code acquis est que c'est désordonné. Donnez-lui du temps et familiarisez-vous avec. Vous pouvez voir des raisons valables pour expliquer pourquoi le code ressemble à ceci avec le temps à venir ...

Answer 3

D'abord, assurez-vous que vous avez une procédure de test robuste pour cela, et qu'il sera réellement testé à nouveau dans profondeur, par plusieurs personnes (vous, QA, ...).

Ensuite, prenez le temps, jour après jour, d'améliorer les petites pièces que vous devez modifier. La clé est d'avoir une gestion qui comprend «pourquoi cela prend plus de temps que prévu». Expliquez que vous devez faire du refactoring et que c'est important à court et à long terme, demandez à d'autres développeurs d'examiner le code existant et confirmez vos arguments.

Answer 4

Welc est un très bon livre. Vous devriez certainement vérifier. Si vous ne voulez pas attendre que le livre arrive, je peux résumer les bits sont importants, je pense

1. Vous devez comprendre votre système. Faire un codage jetable pour comprendre la partie sur laquelle vous devez travailler. Par exemple. Préparez-vous à essayer de faire un peu de travail pour mettre le système à l'épreuve en sachant que vous allez probablement le casser. (Comprenez ce qui s'est mal passé)
2. Recherchez les zones où vous pouvez casser les dépendances. Michael Feathers appelle ces coutures. Ce sont des points où vous pouvez prendre le système existant et le refactoriser pour qu'il soit testable.
3. Lorsque vous travaillez sur le système, ajoutez des tests au fur et à mesure.