Hey, everyone, welcome to Developer Tea. My name is Jonathan Cutrell, and in today's episode I'm going to be talking to you about three techniques you can use, three refactoring techniques you can use today that will take less than five minutes each. Today's episode is sponsored by Linode. With Linode, you can instantly deploy and manage an SSD server in the Linode Cloud. And if you don't have an SSD server in the Linode Cloud, then you're probably headed towards getting one anyway. So we'll talk more about what Linode has to offer and why. It makes sense for you to choose them today. We'll talk about that later on in today's episode. But first, I want to jump into this discussion about refactoring. We have discussed a little bit about refactoring in the past. But today we're going to talk about packing big wins into the small few minutes of your day. After all that is what Developer Tea is all about packing as much as we can into a short amount of time. Now, the process of refactoring code is most effectively done when taken in small steps, one small piece at a time, the smallest slice of your application that you can rewrite at a time. And in today's episode, I'm going to tell you about three specific types of refactoring that you can utilize in your code and each can take five minutes or less. Now it may take a little bit longer depending on which one you are using and depending on your code-based size. But these are very simple refactors, things that don't require large scale refactoring, like creating new classes that encapsulate a major portion of the behavior. That's not what we're talking about. We're talking about very small slices of your application. Because refactoring code at its simplest level means leaving things better than you found them. Whether that means the code is more readable, faster, or otherwise increased in quality or performance, refactoring is the process of bettering code, no matter how big or small. If you use an analogy, for example, of leaving a room better than you found it, sometimes that may mean taking the vacuum cleaner out. It may mean renting a carpet cleaner and actually doing a deep clean or dusting the furniture. But sometimes it can mean simply picking up a piece of trash and throwing it into trash can or straightening a chair or two. If you have wanted to learn how to refactor code but haven't taken the time to learn all of the sophisticated methods, the deep cleaning methods of refactoring, today's episode is for you. I hope to give you a taste of what it feels like to improve code and all it takes is one simple thing, intentionality. Why is it that the trash gets left on the ground? It's not usually because we want to leave the trash on the ground, but because we don't have a compelling reason to pick it up. And we have to choose to leave the room better than we found it. And otherwise, we're going to end up having a lot of trash on the ground and we're going to have to do a large clean-up anyway. Because the reason code goes so long without a refactor, the reason that trash piles up on the ground usually is because it works the way it is. It's not impeding the code from actually working. In other words, why would I choose to fix code that already functions properly? And so we have to recognize the code that works is not necessarily the highest quality. Code that meets the minimum standards can often be improved with some simple refactoring. Now, there is a caveat I'd like to mention before we jump into these refactoring techniques that I want you to understand. Refactoring has been studied and written about by a host of people who have been writing code and performing successful refactors on major code bases for decades. So by no means is this a thorough investigation of what it means to refactor your code base? If you truly want to invest in your career, if you want to invest in your knowledge about refactoring, I suggest you do some deeper research. Not every refactor is as simple as the ones we will outline today. Not every refactoring technique is as simple as the ones we will talk about today. With that said, let's jump into our three simple refactoring techniques for today. The first refactor for today is called the renaming method refactor. In this case, we're talking about a method or a function call depending on the language you are using. Perhaps one of the simplest things you can do to make your code more readable to other developers as well as yourself is rename your methods using concise and clear language. Your method names should explain what the code is doing and all code contained in that method should be described by the method name. For example, if you have a method that's called create user and that method indeed creates a user, but it also sends the user an email or some other kind of notification. Perhaps you should refactor that method name to be create and invite user. At first, that may sound unnecessarily longer verbose or otherwise laborious, but in practice, longer method names are far easier to deal with than implicit code hidden behind a shorter method name. Choose descriptive method names in your code, even if it means the method is significantly longer. This is something you can do relatively quickly in your code, depending on how many locations that particular method is called in. You can also move the functionality from the old method, the old short named method into a new method and then treat the old method as a wrapper around the new method. In other words, call the new method in the body of the old method. This is a common practice for deprecating old methods because in that old method, you can also send a log message to future developers saying, hey, this method is actually deprecated, start using this new better named method instead. So refactoring technique number one, rename methods, rename them to be more verbose if necessary and rename them to be clear. You don't want to have abbreviations, for example, in your method names. And we're going to take a quick break to talk about today's sponsor, Linode, and talk about packing a punch into a small amount of effort. If you have less than $10 a month to spend on your career, which hopefully you do, then Linode may be the perfect place to spend it. We'll talk about why it's less than $10 a month and just a second. Linode has eight data centers and their plans start at $10 a month. You can get a server running in under a minute with hourly billing and a monthly cap on all your plans and your add-on services. Now, the reason I said Linode costs less than $10 a month is because Linode is offering you as a developer to listen to $20 of credit. You can use a Linode server to do pretty much anything with virtual machines for full control. You can log in as root. Of course, you can run a private get server. You can have your own Docker containers, obviously. And if you're concerned about performance, Linode runs on native SSD storage. They have a 40 gigabit internal network and they run on Intel E5 processors as well. On top of this, they have a seven day money back guarantee. And if you missed it earlier, they're giving you $20 just for being a developer to listener. Speaking of performance, Linode is now offering two gigabytes of RAM for only $10 a month. They started that in July. So if you looked at Linode earlier and you didn't think it was worth it, you need to take a second look again, Linode.com slash Developer Teathat will automatically apply the code Developer Tea 20. So you get $20 a credit at checkout. Thank you again so much to Linode for sponsoring today's episode of Developer Tea and of course, you can find all those details in the show notes at spec.fm. So we're talking about refactoring today. I've already given you one technique that you can use in just under five minutes. It's called the renaming method refactor. I've got two more techniques for you today. Technique number two, technique number two is extracting a concept into a method. Now, if you go and look for a refactoring discussion online, you'll see different versions of this concept, the idea that you can take a concept that you can name and turn that into a method. This one's a little bit more complicated. So we'll try to break it down with an example. Let's say you have a conditional in your code. And at first, you just want to check to see if the current time is greater than 7 a.m. Well, that seems relatively simple. So you write that in your conditional. But then you decide that you want to make sure that it's also earlier than 8 p.m. The conditional having both of these parts, it can get easily convoluted, but it still is relatively readable. Of course, while two parts may seem simple, if we start adding more conditional elements to the same statement, it gets significantly more complicated. Let's say we also want to only pass this conditional when it's not between 12 p.m. and 1 p.m. Perhaps we only want to pass the conditional when it's later in the year than September and earlier than mid-December. If we string all of these conditionals into a single statement, we're ultimately dealing with a very difficult to read, incredibly dense line or couple of lines of code. However, let's try to extract some semantically named concepts from this if statement. If our statement is checking that it's later than 7 a.m. and earlier than 8 p.m. then maybe we can reasonably name that concept daytime. If we're checking for times to not fall between noon and 1 o'clock, maybe we can reasonably call that window of time lunch time. If we're looking for dates that fall later than September and earlier than mid-December, we may be able to call this fall or autumn. Now, depending on our application, we may be able to compose these individual concepts into one or two meta-concepts. In this case, we've been talking about hours that may be available for daytime classes at a university during the fall semester. So we may be able to call that concept and therefore create a method called available hours for fall semester. The concept here isn't necessarily about how to write a date range, but rather it's about composing these raw ideas, the raw pieces of code, the hard parts of the code, if you want to call it that, it's about composing those intonamable ideas and using methods in our code to encapsulate those ideas and make it more readable. When you look at your code, you can ask the question, what is this actually doing? And typically, the thing that you respond with could probably be called a method. If you start answering that question in your comments, then you can decide if there are pieces and parts that are representative of a larger idea that has a name. This is a prime opportunity to refactor that concept into its own method rather than letting the concepts stay in its raw form for the next person to try to parse the meaning from. So next time, when you come across that same piece of code that's trying to explain those hours, those available hours for class time in the fall semester, you won't have to try to parse through all of that information in that conditional. You can just read the method name. It's significantly easier to read, significantly easier to deal with. The third and final refactoring technique today is a very simple one. You may not even think that it's a refactoring technique, but indeed it is. It's simply kill dead code. Kill dead code. When you go through the process of developing, there are natural refactoring things that take place without a specific methodology. It's happening constantly. When you're developing something new, you start with an idea, you start with one design solution, realize that it's not really working, maybe slightly shifted, moved to a different design solution. This is a normal workflow and it's typically pretty effective. However, it's all too easy when you're in that process to leave behind dead code. Perhaps it's from an original build or maybe it's a result of a refactor later down the road. Maybe it's a stray comment that isn't relevant anymore or perhaps it's an unused variable or a conditional branch that can never even be hit. Maybe it's a result of copying and pasting code from Stack Overflow. Whatever the case is, if you're looking at a piece of code in front of you right now, if the project is like most projects, there's most likely a piece of dead code that you can identify and delete with little to no consequence. The beauty of tools like Git and other version management software that exists is that you can with pretty much no consequences, delete that kind of dead code and never look back because you can always go back and even in GitHub, visually see that old code, copy and paste it, bring it back to life. A lot of the time, we can be afraid to delete dead code because it may actually be more like, well, zombie code. It still does something. It's just kind of hard to tell how it fits in and it's really more dangerous to try to kill it than it is to just ignore it. To instill confidence in any kind of refactor, it's necessary to have some sort of testing strategy, whether that's an automated testing suite or at the very least a thorough manual testing method that you can run through to verify that your changes, your refactors have not broken the most important parts of the application. Ultimately bugs are extremely difficult to avoid 100%, but with tests in place, refactors like killing dead code become trivial and confidence is increased and your code base is improved and you leave things better than you found them. So the three techniques, they're very quick generally speaking, three techniques. Number one, renaming your method refactor. This is simply making your methods named more correctly, more verbosely in most cases. Number two, the secondary factor is extracting a concept into a method and finally, number three, killing dead code. Thank you so much for listening to today's episode of Developer Tea. I hope I've inspired you to go and make a piece of code better that you're looking at today. Creating code better is not just the job of the senior developer. It's everyone's job. You can always learn how to refactor in the smallest of ways, whether it's renaming your methods or creating a new concept method or cleaning up code by deleting unused code or 100 other things that you can do to make code better. It takes intentionality. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Lynne Ode for sponsoring today's episode of Developer Tea. If you want $20 of free credit at Lynne Ode, that's less than $10 a month for the first year. Go and check it out. Lynne Ode.com slash Developer Tea. Use the code Developer Tea 20 for that $20 of credit. Thank you again to Lynne Ode for being a long time sponsor of Developer Tea. If you're enjoying today's episode of Developer Tea and you don't want to miss out on future episodes, go and click subscribe in whatever podcasting app is open on your phone right now. Thank you so much again for listening and until next time, enjoy your tea.