I once worked on a project that had some tests but the architecture was… let’s say it could be better. There were many files with over a thousand lines of code many classes had too many responsibilities I did not have enough fingers to count them all.

I think I failed to be as effective as I could in this environment for one reason. A very simple reason.

“Coding in the right mindset you did not” said my master. And the master gave me a bunch of dead trees which people commonly refer to as ‘a book’.

Reading Working Effectively with Legacy Code by Micheal Feathers triggered a few thoughts. The book just led me to think differently about legacy code.

And what I found out the hard way is that I should have realized that I was working with legacy code.

Simple isn’t it?

Then I would not have minded putting methods public to be able to test them. At least it allows me to test my code without too many changes.
Then I would not cared if the class I was working on had thousands of lines of code – I would just make sure the bit of code I was modifying was tested.
Then I would not have tried to refactor too much code. Small steps are the key.

I plead guilty. I was trying to hard to remove the design flaws. This slowed me down when I had to add features.

Learn from my mistakes. When working on legacy code, change your mindset. Forget about great and extensible design – or at least don’t make it your priority. You have a job to do. Do it effectively. It might not be glamorous but in the end, you’ll get the features out a bit faster while still improving the test coverage.

One thought on “Mindset”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>