Mindset

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.