Étiquette : legacy code

Risks when changing software

Some questions to answer to:

  1. What changes do i have to make?
  2. How will i know that i’ve done them correctly?
  3. How will i know that i haven’t broken anything?

You can’t minimize software problems by avoiding them. Avoiding changes will make people get rusty at it. Another consequence is fear.

The alternative of avoiding changes is to try harder.

Changing software

Requirements change. Designs that cannot tolerate changing requirements are bad designs.

There are four primary reasons to change software:

  • Adding a feature
  • Fixing a bug
  • Improving the design
  • Optimizing resource usage

There is a very big difference between adding a new feature and changing old behaviour. When adding behaviour we must NOT change or remove behaviour the users already depend on.

Improving the design without changing its behaviour is called refactoring.

Optimization is like refactoring but it has a different goal. Some resource used by the program, time or memory, is changed.

When working on a system we can change three different things:

  • structure
  • functionality
  • resource usage

The Legacy Code Change Algorithm

  1. Identify change points – the places where you need to make the changes
  2. Find test points
  3. Break dependencies – Depenencies are the bigges impediment to testing. Break them to get tests in place.
  4. Write tests
  5. Make changes and refactor

What is legacy code?

Legacy code can have multiple definitions:

  • code we have gotten from someone else
  • a slang-term for difficult-to-change code that we don’t understand
  • code without tests. Without tests we can’t be sure if our code base is getting worse or better. With tests we can change the behaviour of our code quickly and verifiably.

Working Effectively with Legacy Code (Robert C. Martin Series)