Legacy Code : Working With FeedBack

Hello :) , Today We will Talk about Legacy Code and how to make changes inside it by having a source of feedback.

What is a Legacy Code ?

<< Legacy Code is code without tests >> as simple as it is , the first time i read it it hits me. We all know enterprise with legacy code , sometimes we have participated to this legacy code base. ;)
Now we know that the problem is there is no tests , how do you make update or change in legacy code ?

The Source of FeedBack

When making changes we do not want to break anything elsewhere , so M. Feathers said << we shoul have a source of feedback , and this source of feedback is tests >> this drop us to the Legacy Code dilemna When we change code, we should have tests in place. To put tests in place, we often have to change code.

Unit Testing

Indeed some can ask why unit testing ? because It is a small world that tests a small unit of our system. Why Not Larger Tests ? Because the qualities of an unit test which are Fast Running and ** Fas Error Localization** are not the qualities of a larger test for example . And this is preciseley where an unit test is a source of feedback .Thanks to these two qualities we can make a change or an update in a legacy system without fear.

The Legacy Code Change Algorithm

This one is from Michael Feathers in his book Working Effectively with Legacy Code. Look what he says:

The day-to-day goal in legacy code is to make changes, but not just any changes. We want to make functional changes that deliver value while bringing more of the system under test. At the end of each programming episode, we should be able to point not only to code that provides some new feature, but
also its tests. Over time, tested areas of the code base surface like islands rising out of the ocean. Work in these islands becomes much easier. Over time, the islands become large landmasses. Eventually, you’ll be able to work in continents of test-covered code.

beautiful isn't it ;).

Now the Algorithm of change :

1. Identify Change Points
2. Identify Test Points
3. Breaking Dependencies
4. Write Tests
5. Makes Changes and Refactor

What i think about this algorithm ?

In the next few weeks , thanks to JESUS i will share my advice about them. I am going to read more to give you a better understanding.

Thanks for Reading ;)