Refactoring is a simple concept, and yet it takes some learning to come to a point where refactoring is beneficial. Refactoring means making small adjustments to code throughout the life of a system in order to improve many aspects and give better long-term results.<\/p>\n
The purpose for refactoring code can be for readability, creating a more modular design for ease of upgrading or extending, performance improvements, or things like experimentation with new methodologies and technologies. Refactoring code does not change behavior or output. It is only a reworking of the implementation details.<\/p>\n
In programming, there is a practice called Red, Green, Refactor<\/strong>, which is a practice of Test Driven Development.<\/p>\n The purpose of the red<\/strong> phase is to define an aspect of the code you want to implement and prove that the test is being executed via its failure message. If you skip this step, you may end up with a test that doesn\u2019t get run when all your \u201cother\u201d tests show up as green (dead code)<\/em>.<\/p>\n The green<\/strong> step is rather simple: it\u2019s when you write the code to make that test pass.<\/p>\n The refactor<\/strong> step is a very valuable step in which you apply your learned knowledge of good code practices and make small adjustments without changing the codes behavior.<\/p>\n Code that doesn\u2019t get refactored as a system evolves is the common culprit for technical debt. Technical debt is a term used for the increasing amount of work that should be done to make a system more manageable. Without having a good understanding of many design patterns and the simple discipline of small refactoring as you go along, you can end up with quite a kludge of code that needs to be \u201cfixed.\u201d<\/p>\n When a person starts learning how to program, they start learning a process of how to think through problems. They get an initial understanding of setting state, evaluating it, and conditional behavior. This may seem good for learning a language but none of the good coding practices are instilled in them at this stage. This level of knowledge will likely lead to high code coupling and deeply nested conditionals that get harder to wrap your head around or maintain.<\/p>\n There are design patterns that help decouple and remove most of the heavy query method usage, such as Tell Don\u2019t Ask, Eastward Oriented Code, and Monads. Learning to apply patterns such as these will help relieve you of many of the headaches you experienced as a new programmer.<\/p>\n When a person has spent a lot of time with writing heavily coupled code and changing state across objects, it takes a bit of effort to change and think as one should about writing better code.<\/p>\n This is further evident when it comes to writing threaded programs. When a program can have several things try to access or change the same item, you end up with problems. Mutating state with coupling or threading is the source of many issues.<\/p>\n Coupling in programming is when objects know specific things about how to call and use other objects.<\/p>\n For an example of high coupling, imagine a method call like To help decouple, it\u2019s better to move toward one method call on any one object when possible. So in the above example, we can write a method on So now the benefit of decoupling is becoming quite clear. It allows you to maintain large code bases, making change easier to manage.<\/p>\n Decoupling is important when integrating external dependencies. It may seem counterintuitive at first, but \u201ccreating more objects\u201d to act as middle man is a great way to decouple code for easier changes.<\/p>\n Instead of calling the API\/methods of external dependencies directly from various places in your code base, you define your own wrapper object(s) which will have each method call mapped to the appropriate method on your external dependency. This way you can swap your external dependencies one for another as easily as writing another wrapper object with the same methods on it.<\/p>\n You may have heard stories, or you\u2019ve experienced them, where the By design, Rails has a way to organize data and behavior into specific areas to help maintanability and functionality. There are also additional design patterns you may implement along with with their standards. In the above scenario, the code may be implemented something like:<\/p>\n Here, the view and the user model are both doing more than they should; they are not following the single responsibility principle<\/em>. The user model shouldn\u2019t be responsible for organizing the data for presentation, and the view shouldn\u2019t contain too much conditional logic for how it\u2019s rendered. These should be separated out into different objects. A better organization of your code would look like:<\/p>\n Everything has been simplified towards single responsibility<\/em>, and all the code should be much easier to read. Models will be smaller, and you don\u2019t have to guess what the view is doing.<\/p>\n In the controller, it may be wise to employ the Null Object Pattern<\/em> for a There are many resources available to learn about refactoring and design patterns. Here are some excellent resources, many of which I enjoy revisiting to better reinforce my understanding of good practices and design. Many practices are best learned through demonstration, so I highly recommend a look at these.<\/p>\n When it comes to refactoring code for easier understanding and maintenance, it\u2019s often done by creating extra simple representational objects to abstract away complexity.<\/p>\n Smaller amounts of refactoring can be done by following something like a style guide<\/a> with something as simple as swapping out a nested conditional for guard clauses<\/a>. What that does for you is to keep the code from having overly nested indentation toward the right, but rather to have the organization of code more aligned for easier comprehension and a little bit of elegance.<\/p>\n Refactoring is a must for any programmer who wants to be worth their salt. It\u2019s understandable if you haven\u2019t been in the practice of doing it up to now. But once you know better, it\u2019s your responsibility, both to yourself and to others, to better educate yourself in this discipline and to live by it. You should strive to write code in a way that future changes will not be met with great difficulty. So like any athlete, take some time to train yourself and hone your skill. The world thanks you in advance.<\/p>\nInitial Setbacks<\/h2>\n
The Benefit of Decoupling<\/h2>\n
user.profile.address.phone<\/code> and then imagine the program gets changed so that phone<\/code> will now be a method call on a communication<\/code> object on profile<\/code> instead of address<\/code>. If you\u2019re calling methods like this, there is a high chance that this deeply nested call is written many times over your code base. The change to using the communication<\/code> object will require hundreds of changes throughout that code base.<\/p>\nuser<\/code> called phone<\/code>, which calls profile.phone<\/code>. profile<\/code> will likewise call address.phone<\/code> where address<\/code> gets the phone<\/code> object back. So now to call the method, you simply use user.phone<\/code>. To make the change, you only need to change the code in one place: change profile.phone<\/code> to call communication.phone<\/code> instead of address.phone<\/code> and every place in the program that calls user.phone<\/code> will just work without needing to be updated.<\/p>\nRefactoring in Rails<\/h2>\n
User<\/code> model ends up with a massive amount of code in it and the views have overly complex rendering logic in them. These \u201ccode smells\u201d are a good hint that some refactoring may be in order.<\/p>\n\n
\n
UserPresenter<\/code>, where you create a Guest<\/code> object that has all of the same methods as the User<\/code> model and you can call your presenter with something like UserPresenter.new(current_user || Guest.new)<\/code>. This way if no one is logged in to your site, the view can still call the same methods for your user and get the appropriate results for a guest.<\/p>\nLearning Resources<\/h2>\n
\n
Summary<\/h2>\n