Less code is good. Actually the best code is code that is never written.
Code is going to be read by someone else. Less code makes everything easier to understand.
And the what a feeling you get from cleaning code!
Every line of code that can be removed brings a grin
Every method that can be deleted makes me smile.
Every object that can be eradicated makes me laugh.
Act like there is no tomorrow.
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.