Of course, I also write new code and stuff but there are situations when legacy code must be fixed, updated, improved and so on. The bad part is that you rarely get to meet the original author of the modules you'll need to work at.
Well, in this situations, I think one should accept some facts about legacy code:
- it is usually considered good code
- it has been tested
- has brought and most likely still brings money to the company
- because of the above a rewriting decision is unlikely to happen with it
As a child I watched the Zorro series and all that the main character did after catching the bad guys was putting the "Z" from Zorro mark. This is what you should do with software that worked and now encountered unexpected cases. Only touch it where it is not working. Do not try to reorganize code that worked for many years, unless you covered all the cases.
Usually you will need to get familiar with that code. This probably takes months/years in order to reach a good level of understanding.
So here are my recommendations for such cases (I call this the Zorro approach):
- consult original authors or responsible people for guidance
- prefer local hacks to code refactoring/rewriting, unless rewriting is approved and easy to do
- keep documentation about what you did (you or someone else may need that later)
- always have tests (no matter what type: unit tests, validation tests, subsystem tests, etc) to check the code
- always run tests that worked with the previous version of code
- for each hack/patch always add a test with documentation about the problem
- tests imply that previous functionality shouldn't be affected; so don't affect previous functionality
- be proud ?!
- avoid this if possible :)
No comments:
Post a Comment