By continuously improving the design of code, we make it easier and easier to work with — Joshua Kerievsky, Refactoring to Patterns Refactoring is taking an existing, working, code, and make that code better. Okay, but what does it mean “better”? It means better structured, better built, more readable, and more understandable. Your code is easier to work with, it’s easier to add new features, easier to spot and fix bugs, easier to extend and maintain, and it’s a way to stop your code from gradually getting out of control. What refactoring is If you’ve ever looked at a method that was getting a little too long, and found a few lines in it that belong together, separated those out into their own method. And then replaced the original code with a call to that new method. Well, that’s a refactoring, that is the extract method refactoring. It’s a of for improving code that already exists. This code is already written, and it’s already working. We’re not changing what it does. collection small, independent techniques These individual techniques, each one is a single refactoring technique, and they are , and each deal with . often very small one specific common issue There is such thing as that just anyone can follow. But there is a set of techniques to help you to refactor your code. no a set of rules or a specific order Extract Method Refactoring — refactoring.guru Now if you’ve been writing code for awhile, you’ve almost done some of this already. But using the , . formal refactoring technique brings more conscious awareness to that decision It doesn’t replace your intuition, but it gives you some more : questions to ask If you’re trying to split some code, what should you really be looking for? What do you do when there’s a mixture of local and non local variables? Is there any reason why you might not split some code into its own method? — Techniques Categories A useful way to think about the refactoring techniques is to understand they based on the they operate on. can be grouped into several categories different levels of the code Some of them concerned with itself, not worrying about class hierarchies or design patterns. individual methods Then, there are refactorings where we take a slightly higher view. We’re still now being a bit more . looking at the method but aware of our classes Is this method in the right class?. And, we can move up another level of abstraction, not focusing so much on the methods, but more on the . communication between different classes Is class A seem to do nothing but use class B’s methods and properties?. And we’re even another level up. There are techniques really shine in a object oriented application. Are the clues that we should be using more inheritance and polymorphism or indeed less inheritance and polymorphism?. You will see several refactorings that . One refactoring technique has the name “Add Parameter”, but another, is “Remove Parameter”. appear to be the exact inverse of each other And it is, after all, perfectly understandable that the technique you need is sometimes the opposite of another one. What refactoring is not Refactoring is . debugging not Your code already needs to work. It’s not a way to find bugs, you should have fixed those as soon as they happened. So, it’s true, the process of refactoring . But the moment that you start to deal with that. You which is a very different mindset. during you may find bugs have stopped refactoring and you have started bug fixing Refactoring is . performance not This is another very common misconception that we cleaning our code up and that’s going to make it faster. No, code performance is not the goal of refactoring nor even an expectation. . We’ll be able to read the code and understand it faster. Not just individual pieces of code but the bigger application. But, our performance is! Refactoring is adding features not If during this process you add a new feature, you are no longer refactoring. Because in refactoring we of the code. do not change the behavior We might be doing a lot internally, creating new classes, moving functionality from one place to another, renaming, reorganizing. But the end result of the refactoring process doesn’t change the observable behavior of the code. So, any end user who was using our application before would have no idea we did anything at all. We did not fix bugs, we did not make it faster, we did not add features. Why to use refactoring So, why to do refactoring anyway? Ok, so, refactoring adding features, refactoring is not finding bugs, refactoring is not about performance, . is not but we refactor simply because we want to do those things Because well-structured code will make it so much easier to add new features and new capabilities. It will make it easier to start analyzing performance. So we’re refactoring to get the future roadblocks out of our way. And we do refactoring for a reason. If no reason to refactor, then don’t do it. If we have an application written and untouched since a long time ago. It works, it’s fast enough. There’s no conflict with any of their other systems and no features that need to be added. It could be the ugliest code in the world, but, it doesn’t need to be refactored. Because it would be no reason to do so. In the , it can often be to spend time refactoring when it’s not part of the culture, because the benefits aren’t immediately apparent. team culture difficult for teams to get approval Yes, we’re not adding features, we’re not working on performance, we’re not fixing bugs, We bother so we can do those things easier. so why bother? When to use refactoring Refactoring is not an independent stage. When you first learn about refactoring, it sounds like something you do as an independent stage. That you write an application and later you refactor it. Well, you may need to do that from time to time if you have an existing code that’s a mess, but, the intention is that you start to do this all the time. . You write a new class or some new methods, check and test it, and then take a few minutes to scan and make sure it’s refactored as it could be. That as you write code, you refactor as you go In a team environment, a great way to learn refactoring is with . code reviews or paired programming Bringing multiple sets of eyes to the same code. You find different people spot different opportunities for refactoring. And, if you’re a , you need to to applying the individual techniques, particularly those you wouldn’t naturally think about. solo developer pay a little more attention How to refactor ⚠ … We won’t dig into each refactoring technique, what’s the problem it tries to solve, and how to apply it in the code. Most of them are easy to understand, and you can find them in “Where to go next” section below.Start with the common low level techniques, all the way up to more different levels. — The Steps First, . you don’t need to know all the refactorings, just start using them In fact to learn them well, it’s more practical to pick just a handful set of techniques and start to actively apply those. After learning even a few of these refactoring techniques you’ll find yourself naturally writing more modular code, better object-oriented code, of knowing the correct place to put a piece of functionality or a piece of data. start from the bottom, the the lower level, basic refactorings, all the way up. So, how to start? Things like renaming and extracting methods, shortening parameter lists, minimizing un-useful temps, making your conditions easier to read. So, when you’re looking at a part of the code, . just scan through that part of it two or three times What you’re looking for is . not where I can apply refactoring technique X What you’re looking for are the . The things that make this code smells bad. And we use it as an indicator we have something to improve. things the will bring your attention This is what’s refereed to code smells. So, duplicated code, a long method, long parameter lists, too many comments, and the . list goes on But, some code smells , they will . Things like, data clumps or places to push down or pull up methods or fields. don’t come from scanning require close attention Many of the most common programming IDEs, like Visual Studio, Xcode, and Eclipse, will actually help you do many of these refactoring techniques. — Automated Testing We’re . changing code and that brings risk The single best way to prove that the when refactoring is to have a set of you can run on your code . changes you make only do what you intend automated unit tests before and after Automated testing can be done using a like Jnit in Java. test framework Automated testing all the way to test driven development or behavior driven development strategies are extremely complementary to refactoring. Where to go next When you’re comfortable with a set of refactorings and you want to take it further and explore more, then your resources should absolutely include . “ Refactoring Improving the Design of Existing Code ”, by Martin Fowler This book isn’t intended to be read from cover to cover. Most of it is a catalog of refactorings. So it’s more of a reference than tutorial. The (associated with martin fowler’s book) and websites have short summaries, with code examples. refactoring.com refactoring.guru And as you get more comfortable, you may also want to look for resources on . The principles are exactly the same. But there are often . refactoring in your platform or environment platform specific tips and tricks Thanks for reading! If you enjoyed this article, would you give me a few claps by clicking the 👏 button? It helps a lot!
