Recently I've been dealing with code refactoring in my workplace, and therefore I thought about writing an article on it.
In software engineering, code refactoring is the procedure of changing the structure of existing code without impacting its behaviour and functionality.
We need code refactoring because:
✔️It makes it easy to add new code.
✔️The existing code becomes cleaner and more readable after being refactored.
✔️Engineers can understand the code better through refactoring.
✔️Coding becomes more enjoyable and less painful.
Code refactoring can bring in many different advantages:
It makes code more reusable.
It improves the standard of the code.
The code becomes easier to maintain and scale.
Refactoring improves the architecture of the code without changing software behaviour.
However, code refactoring can be a challenging process because:
❌ It's time-consuming: when you start refactoring the code, you don't know how long it will take. Plus, you don't know where to begin to change the code, and this uncertainty may take away some more time.
❌ Re-testing: refactoring may lead an engineer to rewrite some tests and ensure they still pass.
❌ Backward compatibility: the code still needs to work with the older version of the existing code.
❌ Fear factor: some engineers may be afraid of restructuring the code, and the reasons behind this fear can vary. For example, they might be fearful of breaking code that works and the time it may take to rewrite some tests.
❌ Reluctance: not all software engineers see the benefits of restructuring the code (there is this ongoing saying that you should never touch code that works 😁). This leads to engineers being hesitant when it comes to code refactoring.
The major problem that code refactoring addresses are that of code smells.
A code smell is a signal which says that the code has been written without following the best practices.
Well, there are many ways to recognize a code smell.
- Repeated code: the same code appears in multiple locations.
- Large class: a class that contains too much code.
- Long method: a method that has too many parameters. It reduces readability and testability.
- Complexity looks enforced: the design is overly complicated.
- Cyclomatic complexity: this happens when there are too many IF statements or loops.
- Difficult to debug: code becomes difficult to debug.
- Difficult to scale: a program with too many codes smells makes it challenging to add a new feature or implement a small change.
Some standard techniques to refactor code:
Extracting a method: a long and over-complicated method can be extracted into smaller methods. You can also decide to create a whole new class to replace a long method.
Inline method: you can replace the body of a method call with the body of the method itself.
Moving features: if a method uses members of another class, then consider moving that method to the other class.
Consider replacing arrays with Objects.
Break up conditionals and replace nested conditions with guard-clauses (a precondition, for example, doing a null-check at the beginning of an IF statement).
Consider making method calls simpler by renaming a method.
Refactoring also applies to databases.
A change to a database can be:
The structure: you can change the table's name or a column.
Data quality: make changes to improve the data quality stored in the database.
Referential integrity: any data linked to a table should exist, and unused data should be removed from the database.
Architectural: this means enhancing how external applications communicate with the database.
Method: code changes intending to improve overall quality.
Transformations: this refers to changes in the database schema, for example, by adding an extra column.
Overall, I think code refactoring is one of those things that it's painful to do now, but you reap the benefits after. 😁
Are you in favour or against code refactoring? Let me know in the comments.
Thanks for reading my article.
Until next time. 👋🏾
Other articles that you may enjoy reading: