legacy code

How to live with badly written legacy code

Imagine yourself in a situation when you need to add a new functionality to an old and badly written code. What do you think first? “I need to refactor it all!”. Then second thought is coming: “better not to touch it too much” or “I will use a copy-paste pattern” or even “I need to change the job”. The first idea you have of course depends on your experience. In this article I would like to share my thoughts with developers who are struggling against themselves in such a situation.

Why I think Juniors shouldn’t get that kind of code as their first tasks

Inexperienced developers are at the beginning of the road of shaping up their coding style. Seeing so many code smells at the beginning of their career may influence their future craft. It is even hard for them to detect code smells since this comes during practice. They are making bad habits which will be hard to get rid of. It is even worse if there are no guidelines for writing such code and making changes. That’s why I think Juniors should see good examples from the beginning. Ideally, they should work together with experienced developers who can explain what is wrong with this code.

Good, but I’m experienced and I don’t want to see this crap anymore

There is always a solution. The easiest one is just to change your job. Let’s assume it is not an option for you. Sometimes badly written code is not only one worry. Lack of good IDE, source code versioning and unit tests can be bigger problem than the code. Refactoring is limited and risky. Implementing new stuff is also straitened. How to live? I would apply rather pragmatic approach.

Find yourself a mission

Your mental attitude is half the battle. Finding a purpose in something you are doing helps a lot. Let’s imagine you want to polish your craft in any conditions. Start from simplifying your work by mastering the tools you have. Write some shell scripts in order to automate tasks, configure your environment by adding useful aliases, know system commands like grep, find, more, ls. Feel the power of diffand find out how to exit vim. If you have your tools ready, add lacking unit tests for the parts you are supposed to change. This will make you confident during implementation. Then you are ready to do refactoring. Try to use the rule of leaving the place better than it was when you found it. It means when you are changing the code, clean some parts around. Don’t go to deeply with refactoring at once.

Read books which may help you

I recommend you books which can help you to deal with the problem. These are “The Pragmatic Programmer: From Journeyman to Master” by Andrew Hunt and David Thomas, “The Software Craftsman: Professionalism, Pragmatism, Pride” by Sandro Mancuso and “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin. They helped me in changing my thinking about my attitude to many situations I was facing with.

Get help from others

Try not to deal with it alone. I know, nobody wants to touch it. Try to set up a software craftsmanship meetings in your company. You may perform code reviews together in a group, discussing possible approaches and solutions. In order to make meetings more interesting you could discuss topics you are currently interested in. Combining business and pleasure will move work faster.

Conclusion

Programming is not only about writing a good code that anyone can understand. It is often a struggle against yourself. I’m curious how you are dealing with it? Leave a comment.