This is a learning diary post from Uni Helsinki course Software Factory / Facebook Academy – SocketIO team. For more info about this course read “Ready, Set, Start Coding!”.
What is refactoring?
Refactoring is a technique of improving design and implementation without (or hardly) changing the behavior of the code. It is a process of applying series of small behavior-preserving changes that clean up code, reduce the clutter, find code that smells and improve code readability. These changes should be so small that they don’t break existing unit tests, which should be run before and after each change. This way we can reduce the risk of introducing errors.
Refactoring can be seen as a long-term investment that helps to keep your code from decaying over time.
Why we need to refactor your code?
Usually, the first time we implement something, we write code that only works without thinking too much how well it does it. When we continue writing code that only works we constantly increase the technical depth because most of the time we don’t find the best solutions and the cleanest way to implement something, or we don’t realize that a functionality or part of it already exists.
Regular refactoring is a way to ensure that this depth doesn’t grow until the code base becomes uncontrollable.
When should we do refactoring
Finding a good time for refactoring can be sometimes cumbersome since we are not implementing new functionality and it might be hard to see the value of refactoring. It is good practice to have a habit of refactoring code, for example.
- After fixing a bug because this forces us to read code again and by doing so we might find places that could be refactored.
- After code reviews (if they are part of your development process) as other developers might have more optimal solutions for implementing certain functionality.
- Before merge request to verify the quality of your request and that your code meets the conventions of a project.
- Before implementing new functionality.
- Upon noticing you are repeating yourself.
How should we start refactoring
- Extract a class – When you notice that a class is growing up into hundreds lines and it might have multiple responsibilities or the cohesion between the methods inside is low, it might be a good idea to break the class into several smaller ones.
- Extract method (closely related to the one above) – While doing refactoring you might notice that some method inside one class is more related to another one, so move it there.
- Rename methods – If a method name is not describing the functionality well enough.
- Introduce explaining variable – Shortest possible code is not always the best option: If, for example, understanding what a loop, if-clause with an assign operation or a long-chained method call does takes more than a minute introducing an explanation variable could work.
- Remove duplicate code – Remember the DRY principle (Don’t Repeat Yourself) as it is always good to keep your code neat and tidy by removing duplicate functionality.