Deciphering Code Chaos Strategies for Writing Maintainable Code

Welcome to building better developers, the developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we're just talking about a lot of different stuff. We've switched up our formats a little bit. We've gotten off of some of our other seasonal type topics. In this season, we're really getting into some of the things that we hit on a daily, weekly basis. This episode, we're going to talk about something that is near and dear to our hearts because we've been venting just before we hit record. It's about writing code, writing it good, maintainable. Part of the whole discussion is when do you architect a solution and when you just slam that sucker home. On the other side, that's got smoke coming out of his ears right now because this is where we started this whole thing is Mike. Why don't you go ahead and introduce yourself? Hey, thanks, Rob. My name is Mike Kamalach. I'm co-founder of Belpiner and founder of Envision QA. Like Rob said, we're talking about coding standards and coding practices today because I've been working on a project recently that is kind of a hot mess of code. We have duplicated code all over the place and we're trying to figure out best standards and things of that nature. And I guess I'm remiss if I don't introduce myself. If we haven't met, hi, I'm Rob. I am a co-founder of Developed and also founder of RB Consulting. You can go check that stuff out at some point. I want to dive into this discussion and that is the key, I think, is the replication of code that Michael just hit on. What you don't want to do is you don't want to maintain something where to change a feature or to upgrade something, you have to go change it in 15 different places. The whole goal, I mean, one is you don't want to have billions of lines of code because it's just hard to figure out where is the piece of code that you need to fix. What is the thing that's broken? But also if you want to maintain stuff, it is very painful and error prone to have five different places you have to write code to do this new feature, whatever it is. And then you got to make sure that every piece you got it, every piece you've got all the same, you know, the same functionality, particularly if you're like I've seen many times where you may have the code theoretically the same in five different places, but it's not because there's like a little thing that changed here or something that changed there. And so you can't just like copy and paste and put it in each of those and boom, we're off and running. You have to make sure that you're utilizing all the right variables, you got all the right things, that all the context is the same and you have to test every single one of those pieces. So now you're having to test something probably further downstream. So we'll start with that is what are your, especially from a QA and a testing point of view, what are your thoughts in that world about just the example I did, the codes in five different places and we got to go make some changes? So if the code's already there and it's in five different places from a testing perspective, unit testing alone should tell you that, hey, we've got a problem where we've got, we're doing the same functionality in multiple places. You could essentially copy and paste the test, but then now you've duplicated work in the code, now you're duplicating work in the test. And the other problem you might have is whatever classes or methods are calling this code, is it calling the right section? If you have a method here that's doing one thing and you copy that and do it somewhere else, but you change one, but not the other, are you really going to get the changes you need? So having duplicate code, well, from a testing standard, yeah, you can test it, but the problem is from a coder's perspective, how do you know which one to use? It becomes difficult. And really you got to kind of watch that. I mean, yeah, you can copy and paste, but unless the functionality of that method itself is very specific, for example, if you're building like online reports. So if you have a worksheet on one page on one report and it's the same worksheet on another report, but because there are two different reports, potentially you would copy the code from one report to the other report because one report might change in the future. So that's one situation where you might have two different places of code because the sheet itself might be different at some point in two different places. So you don't want to change it on one report and suddenly change it on the other. But with that being said, if you have a universal report or sheet that should be on each one that would never change because you're always displaying all the data, then that should be in a central place. Then you should reuse that for all your reporting purposes. And that, I guess, will reach back a little bit into the object-oriented world. That's really when you want to look at the concept of subclassing something. If you've got that case where you've got two reports that start out, let's say, the same, or the only difference is maybe a little bit of the data, or maybe a couple little variables that you can send in, then maybe it makes sense that those both live as the, we'll call it the report class. But then you see one that now has a lot of changes to it, then maybe what you do is you now just say, hey, I'm going to have a subclass. I'm going to have a child of that report class, and I'm going to do all my customizations there. So at the core, I can have those things flow through, and then I've got my extensions, basically, or my specialties on that other report that get picked up. Now, because I don't want to go too long in this episode because we can't, I do want to flip a little bit to the, all right, we've laid out a problem. Let's talk about the solutions for this. And one of the first things is, as you sort of implied, is that you say, hey, what if we come into this situation? So we're sitting there and we've got to change code, and it's in five different places. And we now have to, we see that, we see that it's replicated. What do we do? Now, there is the tried and true standard of kick it down the road, turn it into technology, tech debt, create a ticket for it, and just move on. However, it may be useful for you to, in that time, go ahead and simplify that thing from the five places down to the one. For example, this is one that I've run into a couple of times where somebody, there were different developers, and you may see this at times, there's different developers that come into this solution, and they've come in at different times. And there hasn't been, they haven't really spent a lot of time learning the code before they got in and started writing functionality. And you end up having two functions that are meant to do the exact same thing. And maybe the name is off by a case difference, or there's an underscore, or it's just a slightly different signature. There's like one extra variable that's sent in or something like that. Those things, and I have been in those where it's like, yeah, you can call either one. Doesn't matter. You're going to get the same result back. Technically, you're going to get the same result back either one. You see something like that. We have so many good refactoring tools, and just if nothing else, global search and replace. Take one of those things, knock it out, put all the code in the other one, and just if you're going to take a little longer to get the code done, that's fine. Take a little longer to get the code done, and feel free to just tell your boss, your customer, whoever it is, this is going to save you in the long run. What are some great, what are some of the approaches you've had? It's interesting you talk about the tools. One of the funny things is, because you mentioned this before we hit record, was some people when they're doing code reviews or you're working on a project, they look at what code changes have been done. If you do too much refactoring or add too many spaces, it looks like you've made a lot of changes when you really haven't. In one of those cases, almost every modern day IDE allows you to do the same thing. A full refactor or reformat of all your code so it can be standardized. There are sites out there where you can go get code style standards. Google's got a site, there's a whole bunch of places for all these IDEs where you can get one, decide what you want like Google, Jasper, whatever. You pick a style, you apply it to your IDE, basically format your code, compile it all, and then go from there. Basically, you create a baseline and you move forward. So that's one approach. The other approach is not only the refactor, but so many tools nowadays not only will do the refactor, but they will also help identify if you have duplicate code within your application. For instance, you can use SonarQube or SonarLin, basically the free version of the cloud paid version. And that will help you identify a lot of places where you have duplicate code, where you have code smells, and other potential problems within your system. Lastly, to address the final part of that is the other thing is, and we'll probably get into this a little bit more, but if you find code that's in multiple places, like for example, the one you just said where you have a method here and a method there, in talking about the object oriented world, there's times when you want to make it, like move it up, make it like a parent, move it into an object, but there's other times where you want to create utility files. For example, one of the projects I've worked on recently actually had multiple methods in different classes on opening up or creating temporary files on the system. And some actually handled the file closure correctly, some did not, some had bad exceptionally. And I think I ended up ripping it out of seven places and creating one files, utils with that method that handled it for everything. So that's kind of the last thing I'll touch on. I'll pass it back to you, Rob. That's actually a great point. I like that last piece because there are, I've been in a few of those where what you end up having is, yeah, you spend a little time rolling all those things up into the util function or method, but then what you end up doing is you can look at all of those and a lot of times you'll find that they do have differences. So you can sort of take them and combine them into the best of all of them combined. So you have something now that properly handles all the different types of exceptions. It does all the resource management. It does all of those things. And even if it doesn't, at least now you've got it at one place. So now you have consistent functionality for that feature. And things like that are so common where it's like, I've seen so often where it's date formatting types of things. If it's not already built into it, actually, even when it is built into the language, there's all these different ways that people will deal with casting and moving dates around. File manipulation is almost always going to be something. Sending emails, sending SMSs, notifications, those kinds of things that are just part of an application. It's amazing how often there's like, or even within little model files that you'll have something that there's all these little format or like little methods that somebody has. It's not really part of the class. They're just like, hey, I just need to reformat this address in this way. And I'm just going to do it here as opposed to pulling out to a utility, which begs the question or pushes it forward to say, hey, if you're writing some little utility thing on your method, I mean, on your class, then think about pulling it off to a utility and just put it out there. So you have a nice little container of here's the things that we may use regardless of what package you happen to be in. Yeah, it may seem like it's a little bit overkill, but there's also stuff like, you know, you don't have to, you make it, depending on the class, the language, you can make it all static. So you don't have to actually instantiate anything. It's basically just like having free flowing functions floating around. There's a lot of ways you can get around it if you're worried about that kind of overhead and you're smirking. So I'm wondering what you're, what you wanted to add on that. So one additional thing I'd like to add to that is a lot of times, especially with legacy code, you have methods that are out there to do specific little tasks like format a string or convert an integer or do some little utility thing that you couldn't do within the, like the code libraries at the time. A lot of times there are so many common code libraries out there now, especially like in the Java world, you have Apache commons, you know, JavaScript has Node.js. They have a lot of different packages you can add on there. And sometimes it's better to just go add a dependency, go add on one of these utility class and rip all this code out, get rid of the stuff that is not tried and true or may be so obsolete that you're getting bugs just because you're using that. And use something that the industry already supports, that the community supports, that has been flushed out, that does work. And then you just plug it in and your code works. I mean, you remove a lot of that unnecessary fluff that's in your code that doesn't need to be there anymore. And that does, that makes it, it does make it a lot easier for others to come behind you and read it and see it as well. Cause they're like, oh, I've seen like Apache commons is a great example, particularly with like the things that have evolved over the last several years, I guess now like JSON stuff and XML stuff, even file manipulation. There's a lot of those things that it's just, yeah, early on it maybe wasn't as good. It was a little clunky, it was a little bit of a pain, but now these, these libraries have progressed to a point where a lot of times there's stuff and it's, yeah, you'll find something that was all done by hand, was all manual. It's like, hey, we have to solve this problem. That's awesome. You did an okay job. But now let's take it to this library where now we can just include it in. We don't have to worry about, you know, keeping our, keeping up ourselves with it. We can just have that library and pick up that read that version or that, you know, that bride and true piece of code. That being said, I think we'll wrap this one up. We'll keep it so we don't go too long because we have done that a few times. And as always, if you have any questions, shoot us an email at info at developernord.com. Check us out at developernord.com. You can see all kinds of posts, lots and lots of content on wide ranges of languages and software development techniques and entrepreneurial stuff as well. And check us out on YouTube, out at youtube.com slash developernord. I believe that's it, slash developernord, our developernord channel. And you can see this plus so many other things that we've put together in the last several years now. As always though, if there's any questions, if you need us to go do a little searching, feel free to ask us and we can probably point you to some examples or maybe even some people that have done some of the same things that you're struggling to get through or, you know, have answers that are even better than ours for your questions. That being said, go out there and have yourself a great day, a great week, and we will talk to you next time. Amazon, anywhere that you can find podcasts, we are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.