In today's episode, we talk about old code. Even though it may seem easier to rip out the old code and replace it entirely, slow down and listen to this episode first! Don't forget to subscribe in whatever podcasting app you use.
In today's episode, we talk about old code. Even though it may seem easier to rip out the old code and replace it entirely, slow down and listen to this episode first!
Don't forget to subscribe in whatever podcasting app you use!
Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and in today's episode I'm going to be talking about the truth about old code. It's easy to look down on code that is old. And when I say old I mean if you look at a GitHub repository and if you're like me you see last updated three years ago. It's easy to think that that code is somehow less than or somehow not as stable as code that has been updated more recently. And perhaps the intuition for this kind of thinking is not off. We want to make sure that the code base is actively being developed. For example if new things are coming out in a language or if deprecations are occurring around a particular API. We want for that code. To be updated and so when we see code that's three years old. Maybe intuitively we're thinking that that code has not been updated to reflect the changes in the API or that code has not been updated to take advantage of new features in the language. But I want to flip the script a little bit and help you think about code a little bit differently particularly old code a little bit differently. While of course an inactive project is going to have issues that an active project may not necessarily have. There's nothing. Particularly wrong with code that is aged code that has been around for a while. So for example let's say there's a Ruby project that you find and you want to use in your project. Maybe a gem like devise or even a gem like can can these are really commonly used gems. For Ruby on Rails projects. If you look at a piece of code in those gems that hasn't been updated in maybe two or three years it's easy to think once again. That that code is somehow. Underperforming that somehow it's been left behind and it's not going to do well. But the real truth is that all code has quite a few advantages over new code. Perhaps the most important advantage that old code has over new code is that it has been used for far longer. So more scenarios of that code being tested in real life. More scenarios have occurred and most of the time bugs that occur in your code are not because of. Language features or API mismatch most of the time those bugs are going to be actually because of an edge case that you didn't think about or improper test coverage and a lot of those things have been uncovered for that older code that old code has been around long enough to be tested in real life to be actually run through its paces. This also applies to your own code not just to projects that you want to use as a part of your project. Like an open source project that we were mentioning before but it also applies to your code so in other words if you have a project that is five or six years old. And you've been working on that project and you've been adding features over time will certainly you may come to a point where you feel like. This project is old and a lot of pieces of it are out of date and we might as well just throw it away and start all over however most of the time in most cases. It is. Much better to refactor the code that you already have. Then it is to start from scratch. Let me say that again in most cases because your old code has the knowledge of time the knowledge of testing over a period of time. And perhaps has a significant number of small changes small fixes as a result of that time tested period as a result of that scenario. It is more likely that you will be. Successful. If you refactor your existing code base then if you were to rewrite your code entirely rewrite the project entirely. Now the success will depend on a few factors. Number one is going to be your testing methods. You need to have a robust testing solution for a refactor to work properly. Because the reality is you've got a code base that may have a bunch of kind of Frankenstein features right. You've added features over time. Or you've. Added bug fixes exceptions to the rules over time and what you want to do is refactor those Frankenstein pieces. Into a nicer code base. That's the typical scenario for a time tested five or six year old project that somebody's trying to refactor. But the only way that you can successfully refactor project like that is if you first have a way of knowing that your new code is not breaking your old code. And that requires some kind of rigorous testing regardless of whether it's. A simulated or manual. But as long as you have a way of verifying that your new code isn't breaking your old code as long as you have some sort of verification process. Then typically you're going to want to choose refactoring over rebuilding even though it feels good to rebuild even though it seems intuitively that a new build a fresh code base is going to perform better than the old code base fixed. You're actually going to run into. All of the same problems that you ran into previously. But now you have to rewrite those same bug fixes. You have to go through the same knowledge gathering processes that you went through over the last five or six years in that previous project. You have to go through all of that again. Now of course there are some benefits to rewriting something entirely from scratch. For example you can build the entire code base test driven first rather than trying to retrofit tests. You can take. Advantage of the latest software packages. But the reality is when you refactor projects you have the opportunity to refactor into those new software packages. What this comes down to is shifting your understanding from thinking about physical objects being upgraded. For example a car like a 1960s car. We think about software that way. What we need to do is shift our thinking away from the physical upgrade into the virtual upgrade. And here's the big difference. Refactoring does not mean that you're sticking with an old system. Refactoring doesn't mean that you're holding on to all of the Frankenstein components. Your existing code base should be treated as knowledge. Your existing code base should be treated as knowledge. And you don't want to throw away that knowledge. You don't want to throw away all of that learning that you spent time gaining. Your refactor is just as effective. As it is. As effective if not more effective than replacing the entire system altogether. So the truth about old code is that sometimes old code is better than new code. Thank you so much for listening to today's episode of Developer Tea. I hope you enjoyed it. I hope that it will help you make better decisions about when you should write something new versus refactoring something that already exists. Most of the time the kind of TLDR version of today's code is not going to be the same. Most of the time refactoring is going to be your friend. So go forth, refactor your code. Thank you so much for listening to today's episode. If you're enjoying Developer Tea, make sure you subscribe in whatever podcasting app you use. It takes just a few seconds. If you open up your phone or if you're listening on a computer, open up your computer to whatever app you are using to listen to this episode. Go ahead and press subscribe. That will ensure that you don't miss out on future episodes. Thank you so much for listening. Thank you so much for listening to Developer Tea. And until next time, enjoy your tea.