Hey, everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking to you about refactoring your software. I'm going to give you a five minute overview and just a high level overview of what exactly refactoring is and when you might want to refactor your software. According to Martin Fowler, if you don't know who Martin Fowler is, go and Google him after you've listened to this episode, Martin is partially responsible for the Agile Manifesto, which was written back in 2001. Martin defines refactoring as the process of changing a software system in such a way that it does not alter the external behavior of the code, yet it improves its internal structure. So imagine that you are building an API, for example, and the API has an interface that users consume or perhaps you're creating another product that consumes that API. To refactor that API, you would not change the endpoints of the API that those users consume or that your product consumes. Instead, you would only change the underlying code. Perhaps the most common way to ensure that you are not changing the external API or the external interface to your code is to have tests that run against that code. When you refactor, you would start with passing tests, so you would look at your code and make sure that it's working and that all of your tests are passing when you start out. Then you would change the code and make sure that you get it back to a passing state. In other words, it's very likely that in the process of refactoring your code, you're going to break something, so you refactor the code and change it to get it back to a green state. You wouldn't change your tests, though. That's the important part of that, is that if you have a test suite, if you have a number of tests that are running against your code and you want to refactor your code, don't change your tests, only change your code one piece at a time until your code is passing all of those tests. Now what exactly is refactoring? We've said that refactoring is changing underline code and that it's not changing the external system, the API, for instance. Perhaps you have a class that you can interact with from other files, from other classes. You wouldn't want to change the class methods or the method names or the actual effect of those methods, but rather you want to change the underlying code. Why would you want to change the underlying code? Now, I'm going to ask you to do something that I normally wouldn't ask you to do. I'm going to ask you to pause the podcast and think about why you might want to change the underlying code. Why would you change code that already is passing tests, already is functioning properly and you aren't even changing that function? Why would you change the underlying code? Go ahead and pause the podcast and think about why you might want to change that underlying code. Now, I'm sure you've come up with some good reasons if you paused the podcast. Even if you didn't, maybe you already have good reasons in mind as to why you would want to refactor code that is already working. Perhaps the most obvious reason to refactor your code is in order to avoid repetition. When you notice that you are repeating the same types of code over and over, then it's likely that you need to create some kind of method to offset that specific repeated piece of code. Whether you create some kind of variable to hold some information that you were repeating previously or perhaps you create a new method, like a private method on a class, to hold some information that you're reusing over and over, this is a very common reason for refactoring your code. The very common reason is when your variable naming is confusing or unclear. This seems trivial, but perhaps one of the most difficult problems in computer science is naming things. We've talked about this on the show before, and it's a pretty famous quote, naming things is a very difficult thing to do. It may come as no surprise that an entire refactoring session may be totally dedicated to renaming variables to something that makes a little bit more sense. Make sure that you are naming your variables something clear, or if you are in a refactoring session, rename variables. It's totally fine to rename variables, especially if they are localized to whatever function or method you are performing at that moment. Make sure your variable naming is clear, not only to you, but also to the person who is reading your code. Variables are cheap, make the variable explicitly clear as to what it is and how it fits in that function or that method. Another example of a time where you may want to refact your code is when your methods are getting entirely too long. Now, a good method typically, at least in Ruby, is going to be somewhere between five and fifteen lines long. There are some arguments over this, there are some really strong opinions in this arena. For me, I like to keep methods down to about three to five lines when possible. And usually, if I wanted to, I could write those methods in one or two lines, but I use those three through five lines to make it a little bit more clear. Now, we said previously that you don't want to change the structure of your class from the outside looking in, so you wouldn't want to rename your methods necessarily, but instead you want to break them up into separate methods that you can compose together. And what this allows you to do is be more explicit about the steps that you're taking. The entire point of these methods being short is that you can be more abstract about the language that you're using and it makes your code much more reasonable and readable for somebody who's coming from the outside in. So create methods that explain what they do in their naming structure and then make sure those methods are short enough and typically that means between five and fifteen lines. I'm going to take a quick break for a sponsor and then I'm going to come back and give you two other times when you might want to refactor your code and then some reasoning behind those situations and why you would want to refactor your code in those situations. I'm so excited to tell you about today's sponsor because there's opportunity for almost anyone with today's sponsor and that is hire.com. On hired software engineers and designers can get five or more job offers in a given week. One of these offers has salary and equity built in up front and there are both full time and contract offers and opportunities available and hired. Users can view the offers from over twenty five hundred companies of all sizes from startups to large public companies and then they can accept or reject the offers before ever talking to any company. So there's never any obligations and it's totally free to use. It's a hundred percent free to use. And normally if you get a job through hired they'll give you a two thousand dollar thank you bonus. But if you use the special link for Developer Teathat will be in the show notes hired will double that bonus to four thousand dollars if you accept a job that's hired.com slash Developer Teanow even if you aren't looking for a job but you know another engineer or a designer who is you can refer them to hired and if they accept a job on hired you will get a one thousand three hundred and thirty seven dollar bonus. That is a huge opportunity pretty much for anyone. So go and check it out hire.com slash Developer Tea. Today I've been talking about refactoring. I've given you a couple of situations where you would probably want to refactor your code. One is when you've noticed that you're using a lot of repetition in your code. The second one is when you're variable naming as confusing or perhaps it's unclear. The third one is when method definitions are getting too long so when a single method is growing to fifteen twenty thirty lines long of course this is a time when you might want to consider refactoring your code. The fourth one is when your classes start to have too many methods. So the idea here is that your classes should be somewhere around a hundred lines long and again there's a lot of disagreement on this point but around a hundred lines long is one opinion out there. I actually hold to this opinion as well. So you're looking at somewhere between five and twenty five methods in a given class. Now that may seem really small to you but the reality is it's going to be much easier for you to deal with these classes. If you can reason about everything in that class in one go. If you can look at that class and see all of the methods that that class contains. Of course we're talking specifically about object oriented programming but this is true for JavaScript as well. When you have a module that holds a lot of functions for example it's very likely that you could move those functions into other modules and benefit from the simplicity that you gain. So how do you do this and also maintain shorter methods. Well one of the best ways to handle this is just to simply create more classes. Now in a future episode we might cover ways that you can discover which methods need to be moved into a different class but there's certainly a lot of material available in determining when and where to move methods out of one class or out of a module perhaps into a new module or class. I'm going to give you one final reason that you may want to refactor your code. Again, this show is not intended to encapsulate all of the reasons why you might want to refactor but just to give you an idea a starting point for thinking about why and when you would want to refactor your code. The final reason would be when your methods have side effects or are doing more than one job. So an example of this is if you are signing up a user and charging them in the same method, it's very likely that you're going to want to eventually be able to sign up a user and not charge them and if you only have one method available then you won't be able to do this and it also makes your code very difficult to test. It's hard to sign up a fake user. Your example of why this is a bad situation to be in is because if you are duplicating your data, if you are pulling down the production database and using it locally to test things in your local environment and you rerun all that data or you seed a bunch of users into your database then you recharge those same users. That's a bad situation to be in. So you want to make sure that your code has only one responsibility per method at least and many people subscribe to the idea that each class should have its own responsibility. So when that previous reason for refactoring that I said when your classes start to have too many methods, the reasoning behind that is that we want classes to only have one sole responsibility. That they should be simple and when that sole responsibility starts to grow out of scope, that's when you want to create a new class. When you notice that your methods are doing more than one thing or if they have side effects that are difficult to test, that is a point at which you want to refactor your code. You want to make sure that each method only does one thing at a time. Now one final note that I want to make about refactoring is that refactoring is not about the functionality of your code. As I said previously, the point is not to make your code functionally different but rather it is to make your code easier to maintain and to extend in the future and that is entirely a human problem. You refactor for yourself and you refactor for other developers who are going to come in and look at your code and change it in the future or extend it or if they just went to a reason about it to learn from it. That's another signifier of when you want to refactor your code. That is when you recognize that your code is difficult to read or when somebody else comes in and says this code is difficult to extend or maintain or perhaps it's difficult to test or it's difficult to write tests for. All of these are reasons why refactoring is an important part of your process. It's something that you're constantly going to do. Martin Feller says that you don't decide to refactor. You refactor as a part of the development process. In a nutshell, remember refactoring happens after you have working code that you have tests for. Once you have tests that describe your working code, then you can move forward and rewrite that code to be more readable by other humans and easier to extend without having to duplicate code and without having to have a human sit down and explain their reasoning for why they did what they did or why they named something, what they named it. Refactoring helps you avoid situations where another programmer or you later on down the road are having a lot of difficulty reading and extending your code. If you're interested in learning a bit more about refactoring and how you would go about the process of refactoring, you can read a book by Martin Feller called Refactoring. It uses Java as its principal language. Of course, that applies to other object-oriented languages. Martin Feller also wrote a Ruby version of this book. It's relatively ubiquitous, so it's likely that you've either seen this cover or you've heard about the book at some point or another. Of course, you can find links in the show notes to these two books. I myself am going through the Ruby version of Martin's book. It is certainly enlightening, so I highly recommend that you check it out if you'd like to learn more about refactoring. Thanks so much for listening to today's episode of Developer Tea. I appreciate each and every moment that you spend with me here on the show. I don't take you for granted. The audience is what makes this show what it is. So thank you so much for listening to this episode. If you or someone you know is looking for a job as a designer or a developer, go and check out today's sponsor, hired.com. Incredible opportunities from over 2,500 companies offering salary and equity, both contract and full time, just so many opportunities there. Make sure you use the special link, hired.com slash Developer Tea, which will actually double your signing bonus if you do end up getting a job through hired. And don't forget that hired also gives out a referral bonus if you refer somebody else. So refer them to hire.com slash Developer Tea. Thank you so much for listening to today's episode and until next time, enjoy your tea.