Pedro Pardal is a software engineer and technical coach. He is dedicated to helping developers and teams improve the delivery of high-quality systems by applying XP practices and craftsmanship software values.
In this talk in the #SDsummit, Pedro places us in the context of the legacy code and defines it as all that code that “is difficult to read, is complex, uncomfortable and even (sometimes) is scary or involves a risk to change”.
He adds we tend to think of legacy code as the result of past developers who did not have enough tools, did not know about SOLID, did not write tests, etc. However, reality proves that all projects are greenfield at the very beginning, and one day they turn into legacy.
In order not to fall into the trap of thinking that “the new code will not be legacy one day”, Pedro proposes to consider factors that make the code end up being complex and uncomfortable and then reflect on how we can take those factors under control.
Which factors make us write legacy code?
- Changing requirements: there are always some requirements and a system is developed based on them. Then, some new requirements appear. After that, we realize our system is not prepared for them and it’s time to change. Sometimes, we try to prevent this kind of change and we make an abstraction that is not the best. So, requirements always change, and it’s a factor to consider when we think about writing legacy code.
- Deadlines: software projects are “for yesterday”. We always think that we can go alive and then we can improve the code. This moment never comes.
- Developers: write software is a social activity: we do it in teams. In a team, there are different visions, new people and people who left. So, it’s another factor to consider when thinking about legacy code.
How can we control these factors?
Knowing that the factors described above are unavoidable, what we can steel will apply a “contrary force” to them to keep them controlled and thus try to make the software deteriorate as little as possible.
Some tips:
- Improve skills to be more productive: use IDE suggestions, auto-fixes, automatic refactors. Create the habit of doing katas that improve your skills. In the end, athletes must train and then compete. Here it should be the same.
- Try to comply with the 4 rules of simple design by Ken Beck.
- Having a certain “intolerance” for “bad” code: this is achieved by knowing the code smells, SOLID, writing code with TDD, etc.
- Improve the way we work in teams: change routines, habits, do retrospectives, learn in teams, create team’s agreements.
- Use forcing functions: changing the context to make us do the things in the way we want to have them done. It’s always better to fit the process and not to pretend we remember steps or agreements.
Conclusion
At the end, reasons for developing legacy code are timeless: they were present 10 years ago, are present now, and will be present in the future.
Pedro proposes we be gardeners and to take care of our codebase as a garden.
He closes the talk by giving us great advice: every day spend 10 minutes to improve some code that has bothered us to see, it can be simply by applying automatic refactors. If all team members do that, little by little we will be working on a more pleasant and less painful code.
You can see Pedro’s talk by clicking on this link:
About the author:
