3 Refactoring Techniques You Can Employ In Under 5 Minutes
Summary
This episode of Developer Tea focuses on practical, incremental refactoring techniques that developers can implement quickly to improve code quality. Host Jonathan Cottrell introduces three specific refactoring methods that each take less than five minutes to implement, emphasizing that improving code doesn’t always require large-scale rewrites.
The first technique is the renaming method refactor, where developers should rename methods to be more descriptive and verbose, even if it means longer method names. The host suggests that clear method names that accurately describe functionality are more valuable than short, cryptic names. He provides an example where a method called ‘createUser’ that also sends notifications might be better named ‘createUserAndInviteUser’ to be more transparent about its actual behavior.
The second technique involves extracting concepts into methods. When code contains complex conditionals or logic that represents a specific concept, developers should extract that logic into a named method. This makes the code more readable and maintainable by encapsulating complex logic behind descriptive method names. The host uses the example of checking for ‘available hours for fall semester’ as a concept that could be extracted from multiple conditional checks.
The third technique is killing dead code - identifying and removing unused code, stray comments, or conditional branches that can never be executed. The host emphasizes that with version control systems like Git, developers can confidently delete dead code knowing they can always retrieve it if needed. He notes that having a testing strategy (automated or manual) helps build confidence when removing code.
Throughout the episode, Cottrell compares refactoring to ‘leaving a room better than you found it’ - sometimes it requires deep cleaning, but often it’s as simple as picking up a piece of trash. He stresses that refactoring is everyone’s responsibility, not just senior developers, and that small, intentional improvements can prevent larger problems from accumulating over time.
Recommendations
Tools
- Linode — Cloud hosting service mentioned as the episode sponsor, offering SSD servers starting at $10/month with eight data centers and hourly billing.
- Git — Version control system mentioned as enabling developers to confidently delete dead code since they can always retrieve previous versions if needed.
Topic Timeline
- 00:00:00 — Introduction to refactoring techniques — Jonathan introduces the episode’s focus on three refactoring techniques that take less than five minutes each. He explains that refactoring is most effective when done in small steps and compares it to leaving a room better than you found it - sometimes requiring deep cleaning, but often just needing small improvements.
- 00:04:27 — First technique: Renaming method refactor — The first technique involves renaming methods to be more descriptive and clear. Jonathan emphasizes that method names should explain what the code does, and all functionality within a method should be described by its name. He suggests that longer, more verbose method names are better than short, cryptic ones, and provides an example of renaming a method from ‘createUser’ to ‘createUserAndInviteUser’ when it also sends notifications.
- 00:06:31 — Sponsor segment: Linode — Jonathan discusses the episode’s sponsor, Linode, highlighting their cloud hosting services. He mentions that Linode offers SSD servers starting at 20 credit for Developer Tea listeners using the code ‘developerT20’. The segment emphasizes Linode’s performance features including 40-gigabit internal networks and Intel E5 processors.
- 00:08:26 — Second technique: Extracting concepts into methods — The second technique involves extracting complex logic or concepts into named methods. Jonathan explains that when code contains conditionals or logic representing a specific idea, developers should create a method with a descriptive name for that concept. He uses the example of checking for ‘available hours for fall semester’ which could combine multiple time and date checks into a single, readable method call.
- 00:12:11 — Third technique: Killing dead code — The third technique is identifying and removing dead code - unused variables, unreachable conditional branches, or outdated comments. Jonathan notes that with version control systems like Git, developers can confidently delete dead code since they can always retrieve it if needed. He emphasizes the importance of having a testing strategy to verify that removing code doesn’t break functionality.
- 00:14:30 — Recap and conclusion — Jonathan recaps the three techniques: renaming methods, extracting concepts into methods, and killing dead code. He stresses that refactoring is everyone’s responsibility and encourages listeners to make small improvements to code they work with. The episode concludes with a reminder about the Linode sponsorship offer and encouragement to subscribe to the podcast.
Episode Info
- Podcast: Developer Tea
- Author: Jonathan Cutrell
- Category: Technology Business Careers Society & Culture
- Published: 2016-09-05T09:00:00Z
- Duration: 00:16:12
References
- URL PocketCasts: https://podcast-api.pocketcasts.com/podcast/full/cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263/41d56d0e-25d4-419f-be26-191c422b2c0a
- Episode UUID: 41d56d0e-25d4-419f-be26-191c422b2c0a
Podcast Info
- Name: Developer Tea
- Type: episodic
- Site: http://www.developertea.com
- UUID: cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263
Transcript
[00:00:00] Hey, everyone, welcome to developer team. My name is Jonathan Cottrell. 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.
[00:00:17] 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.
[00:00:33] 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.
[00:00:46] 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 team is all about packing as much as we can into a short amount of time.
[00:01:03] 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.
[00:01:16] 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 base size. But these are very simple refactors, things that don’t require, you know, large, 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 code.
[00:01:46] 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.
[00:02:05] 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.
[00:02:16] 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 in the trash can or straightening a chair or two.
[00:02:27] 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.
[00:02:39] I hope to give you a taste of what it feels like to improve code.
[00:02:44] And all it takes is one.
[00:02:46] One simple thing.
[00:02:48] Intentionality.
[00:02:49] Why is it that the trash gets left on the ground?
[00:02:52] 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.
[00:02:59] And we have to choose to leave the room better than we found it.
[00:03:03] 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 cleanup anyway.
[00:03:10] Because the reason code goes so long without a refactor, the reason that trash piles up on the ground,
[00:03:16] usually is because it works the way it is.
[00:03:20] It’s not impeding the code from actually working.
[00:03:23] In other words, why would I choose to fix code that already functions properly?
[00:03:28] And so we have to recognize that code that works is not necessarily the highest quality.
[00:03:34] Code that meets the minimum standards can often be improved with some simple refactoring.
[00:03:40] Now, there is a caveat I’d like to mention before we jump into these refactoring techniques,
[00:03:45] that I want you to understand.
[00:03:47] Refactoring has been studied and written about by a host of people who have been writing code
[00:03:53] and performing successful refactors on major code bases for decades.
[00:03:58] So by no means is this a thorough investigation of what it means to refactor your code base.
[00:04:05] If you truly want to invest in your career, if you want to invest in your knowledge about refactoring,
[00:04:11] I suggest you do some deeper research.
[00:04:14] Not every refactor is.
[00:04:15] Not every refactor is as simple as the ones we will outline today.
[00:04:18] Not every refactoring technique is as simple as the ones we will talk about today.
[00:04:22] With that said, let’s jump into our three simple refactoring techniques for today.
[00:04:27] The first refactor for today is called the renaming method refactor.
[00:04:33] In this case, we’re talking about a method or a function call,
[00:04:36] depending on the language you are using.
[00:04:38] Perhaps one of the simplest things you can do to make your code more readable to other developers,
[00:04:43] as well as yourself,
[00:04:46] is rename your methods using concise and clear language.
[00:04:50] Your method names should explain what the code is doing,
[00:04:53] and all code contained in that method should be described by the method name.
[00:04:59] For example, if you have a method that’s called createUser,
[00:05:03] and that method indeed creates a user,
[00:05:06] but it also sends the user an email or some other kind of notification,
[00:05:11] perhaps you should refactor that method name to be
[00:05:14] createUser,
[00:05:15] and inviteUser.
[00:05:18] At first, that may sound unnecessarily long or verbose or otherwise laborious,
[00:05:22] but in practice, longer method names are far easier to deal with
[00:05:27] than implicit code hidden behind a shorter method name.
[00:05:32] Choose descriptive method names in your code,
[00:05:34] even if it means the method is significantly longer.
[00:05:38] This is something you can do relatively quickly in your code,
[00:05:41] depending on how many locations that particular method is called in.
[00:05:45] You can also move the functionality from the old method,
[00:05:49] the old short-named method,
[00:05:51] into a new method,
[00:05:54] and then treat the old method as a wrapper around the new method.
[00:05:58] In other words, call the new method in the body of the old method.
[00:06:02] This is a common practice for deprecating old methods,
[00:06:05] because in that old method,
[00:06:06] you can also send a log message to future developers saying,
[00:06:10] hey, this method is actually deprecated.
[00:06:13] Start using this new,
[00:06:15] better-named method instead.
[00:06:17] So refactoring technique number one,
[00:06:19] rename methods.
[00:06:22] Rename them to be more verbose, if necessary,
[00:06:25] and rename them to be clear.
[00:06:26] You don’t want to have abbreviations, for example, in your method names.
[00:06:31] And we’re going to take a quick break to talk about today’s sponsor, Linode,
[00:06:34] and talk about packing a punch into a small amount of effort.
[00:06:40] If you have less than $10 a month to spend on your career,
[00:06:44] which, hopefully, you’re going to be able to do,
[00:06:45] which, hopefully, you’re going to be able to do,
[00:06:45] then Linode may be the perfect place to spend it.
[00:06:48] We’ll talk about why it’s less than $10 a month in just a second.
[00:06:52] Linode has eight data centers,
[00:06:54] and their plans start at $10 a month.
[00:06:57] You can get a server running in under a minute
[00:06:58] with hourly billing and a monthly cap
[00:07:01] on all your plans and your add-on services.
[00:07:03] Now, the reason I said Linode costs less than $10 a month
[00:07:06] is because Linode is offering you,
[00:07:08] as a developer, T-listener, $20 of credit.
[00:07:11] You can use a Linode server to do pretty much anything with.
[00:07:14] Virtual machines for full control.
[00:07:16] You can log in as root, of course.
[00:07:18] You can run a private Git server.
[00:07:20] You can have your own Docker containers, obviously.
[00:07:22] And if you’re concerned about performance,
[00:07:24] Linode runs on native SSD storage.
[00:07:27] They have a 40-gigabit internal network,
[00:07:29] and they run on Intel E5 processors as well.
[00:07:32] On top of this, they have a seven-day money-back guarantee.
[00:07:35] And if you missed it earlier,
[00:07:36] they’re giving you $20 just for being a developer T-listener.
[00:07:40] Speaking of performance,
[00:07:41] Linode is now offering two gigabytes,
[00:07:44] two gigabytes of RAM for only $10 a month.
[00:07:46] They started that in July.
[00:07:47] So if you looked at Linode earlier
[00:07:49] and you didn’t think it was worth it,
[00:07:51] you need to take a second look.
[00:07:53] Again, linode.com slash developer T.
[00:07:56] That will automatically apply the code developer T20.
[00:08:00] So you get $20 of credit at checkout.
[00:08:03] Thank you again so much to Linode
[00:08:04] for sponsoring today’s episode of Developer T.
[00:08:07] And of course, you can find all those details
[00:08:08] in the show notes at spec.fm.
[00:08:12] So we’re talking about refurbishment,
[00:08:14] refactoring today.
[00:08:15] I’ve already given you one technique
[00:08:17] that you can use in just under five minutes.
[00:08:21] It’s called the renaming method refactor.
[00:08:24] I’ve got two more techniques for you today.
[00:08:26] Technique number two,
[00:08:28] technique number two is extracting a concept into a method.
[00:08:33] Now, if you go and look for a refactoring discussion online,
[00:08:36] you’ll see different versions of this concept.
[00:08:40] The idea that you can take
[00:08:43] a concept that you can name
[00:08:45] and turn that into a method.
[00:08:47] This one’s a little bit more complicated,
[00:08:48] so we’ll try to break it down with an example.
[00:08:51] Let’s say you have a conditional in your code.
[00:08:54] And at first, you just want to check to see
[00:08:56] if the current time is greater than 7 a.m.
[00:09:00] Well, that seems relatively simple,
[00:09:02] so you write that in your conditional.
[00:09:04] But then you decide that you want to make sure
[00:09:06] that it’s also earlier than 8 p.m.
[00:09:09] The conditional having both of these parts,
[00:09:11] it can get easily convoluted,
[00:09:13] but it still is relatively readable.
[00:09:15] Of course, while two parts may seem simple,
[00:09:17] if we start adding more conditional elements
[00:09:19] to the same statement,
[00:09:22] it gets significantly more complicated.
[00:09:24] Let’s say we also want to only pass this conditional
[00:09:27] when it’s not between 12 p.m. and 1 p.m.
[00:09:31] Perhaps we only want to pass the conditional
[00:09:33] when it’s later in the year than September
[00:09:36] and earlier than mid-December.
[00:09:39] If we string all of these conditionals
[00:09:41] into a single statement,
[00:09:43] we’re ultimately dealing with a very difficult-to-read,
[00:09:47] incredibly dense line or couple of lines of code.
[00:09:51] However, let’s try to extract
[00:09:53] some semantically named concepts
[00:09:56] from this if statement.
[00:09:58] If our statement is checking that it’s later than 7 a.m.
[00:10:01] and earlier than 8 p.m.,
[00:10:03] then maybe we can reasonably name that concept daytime.
[00:10:07] If we’re checking for times to not fall
[00:10:09] between noon and 1 o’clock,
[00:10:11] maybe we can reasonably,
[00:10:13] reasonably call that window of time lunchtime.
[00:10:16] If we’re looking for dates that fall later than September
[00:10:19] and earlier than mid-December,
[00:10:21] we may be able to call this fall or autumn.
[00:10:24] Now, depending on our application,
[00:10:26] we may be able to compose these individual concepts
[00:10:29] into one or two meta-concepts.
[00:10:32] In this case, we’ve been talking about hours
[00:10:34] that may be available for daytime classes
[00:10:37] at a university during the fall semester.
[00:10:40] So we may be able to call that concept
[00:10:42] and therefore create a method called
[00:10:45] available hours for fall semester.
[00:10:48] The concept here isn’t necessarily about
[00:10:50] how to write a date range,
[00:10:52] but rather it’s about composing these raw ideas,
[00:10:56] the raw pieces of code,
[00:10:57] the hard parts of the code,
[00:10:59] if you want to call it that.
[00:11:01] It’s about composing those into nameable ideas
[00:11:05] and using methods in our code
[00:11:06] to encapsulate those ideas
[00:11:08] and make it more readable.
[00:11:11] When you look at your code,
[00:11:12] you can ask the question,
[00:11:13] what is this actually doing?
[00:11:16] And typically, the thing that you respond with
[00:11:18] could probably be called a method.
[00:11:21] If you start answering that question in your comments,
[00:11:24] then you can decide if there are pieces and parts
[00:11:26] that are representative of a larger idea
[00:11:29] that has a name.
[00:11:31] This is a prime opportunity to refactor that concept
[00:11:34] into its own method
[00:11:35] rather than letting the concept stay in its raw form
[00:11:39] for the next person to try to parse
[00:11:41] the meaning of the concept.
[00:11:41] So if you’re going to do that,
[00:11:41] you’re going to have to do a lot of work
[00:11:41] and you’re going to have to do a lot of work
[00:11:42] So next time when you come across that same piece of code
[00:11:45] that’s trying to explain those hours,
[00:11:48] those available hours for class time in the fall semester,
[00:11:51] you won’t have to try to parse through
[00:11:53] all of that information in that conditional.
[00:11:55] You can just read the method name.
[00:11:58] It’s significantly easier to read,
[00:12:00] significantly easier to deal with.
[00:12:02] The third and final refactoring technique today
[00:12:05] is a very simple one.
[00:12:07] You may not even think that it’s a refactoring technique,
[00:12:10] but indeed it is.
[00:12:11] It’s simply kill-dead-code.
[00:12:14] Kill-dead-code.
[00:12:16] When you go through the process of developing,
[00:12:19] there are natural refactorings that take place
[00:12:21] without a specific methodology.
[00:12:23] It’s happening constantly.
[00:12:25] When you’re developing something new,
[00:12:26] you start with an idea,
[00:12:28] you start with one design solution,
[00:12:29] realize that it’s not really working,
[00:12:31] maybe slightly shift it,
[00:12:33] move to a different design solution.
[00:12:34] This is a normal workflow
[00:12:36] and it’s typically pretty effective.
[00:12:38] However, it’s all too easy
[00:12:40] when you’re in that process.
[00:12:41] If you’re in that process to leave behind dead code,
[00:12:44] perhaps it’s from an original build
[00:12:47] or maybe it’s a result of a refactor later down the road.
[00:12:51] Maybe it’s a stray comment that isn’t relevant anymore
[00:12:55] or perhaps it’s an unused variable
[00:12:57] or a conditional branch that can never even be hit.
[00:13:00] Maybe it’s a result of copying and pasting code
[00:13:03] from Stack Overflow.
[00:13:05] Whatever the case is,
[00:13:06] if you’re looking at a piece of code in front of you right now,
[00:13:09] if the project is like
[00:13:10] most projects,
[00:13:12] there’s most likely a piece of dead code
[00:13:14] that you can identify and delete
[00:13:17] with little to no consequence.
[00:13:19] The beauty of tools like Git
[00:13:21] and other version management software
[00:13:23] that exists is that you can,
[00:13:25] with pretty much no consequences,
[00:13:27] delete that kind of dead code
[00:13:29] and never look back
[00:13:30] because you can always go back
[00:13:31] and even in GitHub,
[00:13:33] visually see that old code,
[00:13:35] copy and paste it,
[00:13:36] bring it back to life.
[00:13:37] A lot of the time,
[00:13:39] we can be afraid
[00:13:39] to delete dead code
[00:13:41] because it may actually be more like
[00:13:43] zombie code.
[00:13:45] It still does something.
[00:13:46] It’s just kind of hard to tell how it fits in
[00:13:49] and it’s really more dangerous to try to kill it
[00:13:52] than it is to just ignore it.
[00:13:54] To instill confidence in any kind of refactor,
[00:13:58] it’s necessary to have some sort of testing strategy,
[00:14:01] whether that’s an automated testing suite
[00:14:03] or at the very least,
[00:14:05] a thorough manual testing method
[00:14:07] that you can run through to verify
[00:14:09] that your changes,
[00:14:10] your refactors,
[00:14:11] have not broken the most important parts
[00:14:13] of the application.
[00:14:15] Ultimately,
[00:14:15] bugs are extremely difficult to avoid 100%,
[00:14:18] but with tests in place,
[00:14:20] refactors like killing dead code become trivial
[00:14:23] and confidence is increased
[00:14:25] and your code base is improved
[00:14:27] and you leave things better than you found them.
[00:14:30] So the three techniques,
[00:14:32] they’re very quick,
[00:14:33] generally speaking,
[00:14:34] three techniques.
[00:14:35] Number one,
[00:14:36] renaming your method refactor.
[00:14:38] This is simply making your methods named more correctly,
[00:14:42] more verbosely in most cases.
[00:14:45] Number two,
[00:14:46] the second refactor is extracting a concept into a method.
[00:14:51] And finally,
[00:14:51] number three,
[00:14:52] killing dead code.
[00:14:54] Thank you so much for listening to today’s episode of Developer Tea.
[00:14:58] I hope I’ve inspired you to go and make a piece of code better
[00:15:01] that you’re looking at today.
[00:15:03] Making code better is not just the job of the senior developer.
[00:15:08] It’s everyone’s job.
[00:15:09] You can always learn how to refactor in the smallest of ways,
[00:15:14] whether it’s renaming your your methods or creating a new concept method
[00:15:19] or cleaning up code by deleting unused code
[00:15:23] or a hundred other things that you can do to make code better.
[00:15:26] It takes intentionality.
[00:15:28] Thank you so much for listening to today’s episode of Developer Tea.
[00:15:31] Thank you again to Linode for sponsoring today’s episode of Developer Tea.
[00:15:36] If you want $20 of free credit,
[00:15:38] at Linode,
[00:15:39] that’s less than $10 a month for the first year.
[00:15:42] Go and check it out.
[00:15:42] Linode.com slash Developer Tea.
[00:15:45] Use the code Developer Tea 20 for that $20 of credit.
[00:15:48] Thank you again to Linode for being a longtime sponsor of Developer Tea.
[00:15:53] If you’re enjoying today’s episode of Developer Tea and you don’t want to miss
[00:15:56] out on future episodes, go and click subscribe.
[00:15:59] And whatever podcasting app is open on your phone right now.
[00:16:02] Thank you so much again for listening.
[00:16:04] And until next time, enjoy your tea.
[00:16:08] Bye.