Refactoring, the project best friend

Helping you to improve your code conception

Hi! Today we’re going to talk about refactoring.

In computer programming and software design, code refactoring is the process of restructuring existing computer code — changing the factoring — without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality. Wikipedia

The content of this article is based on Martin Fowler’s Refactoring book with some additional notes that I took while I was reading the book, and text revisions by Cesar Morigaki. I strongly recommend that you read it for further more information, it provides several methods (the catalog) for refactoring your code and also some insights for good code conception.

1: Test legacy code when possible.

Make sure that the code that you are going to refactor has tests, at least unit test. If you change the code and you do not have tests, you cannot be sure if the behavior of the new code is the same as before. Working on legacy projects some times is difficult to have tests due the architecture of the project, but you should try write some anyway, this can avoid future bugs;

2: Run tests after each change

Test after each change. When you have small changes to tests is easier to find bugs, so this will save you some time of debugging. Also if I can refactor my code and be quite sure that I didn’t introduce any bugs because my tests went green, then I can consider myself satisfied with sufficiently good tests;

3: Leave the code better than you find it

Always leave the code better than you find it. Classic, this does not mean that you need to refactor all the code according to the best patterns or architectures, just leave better than you find, improve names (of functions variables), remove some code that is not needed … Small changes together have big impact. (Atomic Habits by James Clear, it is a different context but works the same.);

4: Should be easy to maintain.

The true test for your code is how easy he is to change, (keep this in mind). A normal project always have new features, or changes to implement, so how easy it is to do this in your project? Also we structure our software to facilitate changes, after all, software must be soft;

5: Open-closed

When implementing new features in the project you should not need to change the current code, (SOLID O Open Closed) (Clean Architecture). Also when you are doing a refactor the goal is not add new code, only restructure the actual code. If a change in a record causes a field in another record to change, it is a sign that there is a field in the wrong place;

6: Hold the pressure

When (N) people are pressing you to simply walk faster, it is sometimes necessary to say. Wait, I have to consult the map and find the fastest way;

7: KISS (keep it simple, stupid)

Implement software that solves only the needs currently understood, but makes the design of that software excellent for those needs. As my understanding of user’s needs changes, I use refactoring to adapt the architecture according to new demands;

8: Tweak afterwards

Refactoring can certainly slow software down, but it can also make it more conducive to performance tweaks. Perfomance some times can be handled only when you understand what is happening;

9: Measure

Don’t speculate about problems in your software, make measurements and understand what’s going on. You can not speak about something that you do not understand;

10: Iterate quickly

A well factored code provides time to invest in performance-oriented adjustments, I can also add functionality more quickly. It gives me more time to stay in the performance. Running a profiler ensures that I spend that time in the right place;

11: Comment only the necessary

A block of code with a comment that tells what it does can be replaced by a method whose name is based on the comment. Also when you need to write a comment, try to refactor the code first, so that any comment becomes superfluous, comments help explain why you did something;

12: Code smells

Avoid leaving code smells in your code like mysterious name, duplicate code, long function, long parameter list, global data, changeable data or mutable data. Code smells are when you see some code and something on it does not smell good, for example, two duplicated methods may work as they are, but they will be nothing more than fertile ground that will pray for bugs in the future. Whenever there is duplication, there is a risk that a change in one copy will not be made in the other. In general, duplicates are difficult to find …

13: Rely on git to remember the code history

I think I will need this kind of thing someday, if all these resources are being used it is worth it, but otherwise get rid of them. Do not always think in everything in thee future, think in the present also, sometimes leave dead code, to use it in the future can create a mess. Git is here use it;

14: Immutability

Instead of returning the instance of objects from a data source always return a copy, so you prevent someone from changing the current instance. Also write unit tests to ensure that when you return an instance of an object it will not be modified, when you do return the instance you cannot know what will happen with that data. I can pass on an immutable piece of data to other parts of the program and not worry about the fact that it can change without the method that includes it being aware of the change;

15: Create structured data

Encapsulating data helps us to see when data structures are modified, when you access data directly in a variable for example is difficult to track and know who is using or changing it, when you have it encapsulated in a method for example, you can handle this more easy. The secret to good modular design is encapsulation. An encapsulation means that the modules need to know less about other parts of the system. To achieve this modularity, it is necessary to ensure that the related software elements are grouped and the links between them are easy to find and understand;

16: Composable solution

When it is necessary to replace an algorithm, I have to make sure that I decompose the method as much as possible. Replacing a large and complex algorithm is very difficult, just making it simpler can I make substitution more controlled, like extracting in more methods or creating a structure for it.

17: SRP (Single Responsibility principle)

Any variable with more than one responsibility must be replaced by several variables, one for each responsibility. Using a variable for two different tasks is very confusing for the reader.

18: Do not modify the input object

Avoid modifying input parameters of a function, you have the risk of modifying the value and whoever called the function does not notice that the value has been changed and causes inconsistencies in behavior, for example the same value can be passed to your function and after it be used and another function;

19: Nested conditionals

Nesting conditionals in some cases mask the true meaning of what is happening in the function, try using guard cases to get out of function in those cases. Example: if (number < 2) return, in this way you do not need to add if validations in your functions;

20: Avoid params flags

Always make explicit functions available for the tasks to be performed that are a clearer option, than using flag parameters to indicate which execution should be done;

Some quotes:

That's it, let's code? I hope this article helps you! See you in the next post.

Photo by Hitesh Choudhary on Unsplash

Be brave and boldly go where no man has gone before. Let's discover the future!