• WritingLegacyCode

Are you Writing “Legacy Code”? Practical Metrics for Agile Development By: Jeff Grover and Zhon Johansen

You’ve heard programmers cursing that “old code”, written by “that one programmer” (who is most likely not with the company anymore). Every time a modification to the system touches it, it takes much longer to complete, and results in kludgy work-arounds and defects. Yes, it’s the dreaded “legacy code”. But what exactly characterizes this type of coding, and how does it come into existence? Chances are that you, or someone who works with you, is busy writing “legacy code” right now. The reduced rigor of agile development methodologies would seem to breed “legacy coding”, but valuing rapid feedback to continuous changes can actually work to your advantage, if you know how to “smell“ your code by tracking a few simple and practical (if unorthodox) metrics.

Four Earmarks of Legacy Code:

1. Confusing for other programmers to read and follow
2. Difficult to debug
3. Resistant to change
4. “Working” (or mostly so) for some time.

Four Strategies for Reducing Legacy Code

1. Reveal your intent to your fellow programmers, not just the computer
2. Prove to other programmers that your code works with unit tests
3. Reduce debugging by keeping tests up to date as changes are made and defects are found
4. Create a an appropriate place for everything, and put everything in only one place

<Code Snippet showing refactor from big, hard to follow method with short variable names and duplication to well-factored, small functions, big, descriptive names... no duplication>

Four Practical Metrics to Track:

1. Test coverage (especially unit tests)
2. Method length
3. Code duplication
4. Class, method and variable names