In this series of posts , I try to share with you some of my highlights on Clean Code Chapters.
Lots of people argue about the necessity of applying clean code principles and whether spending time on refactoring is an important step of the software development process or just a waste of time.
In this post, I discuss some arguments that discourage spending efforts on cleaning code.
Argument : Writing cleaner classes results in a lot of small classes which makes it harder to absorb to the big picture.
Usually some initial efforts should be exerted to understand and follow the code but do you prefer to read a short cohesive class that is only doing one thing or a mega size class that affects a lot of components and is coupled with multiple dependencies ?
Which design would help you find the part you want to change or augment and which design would make the code modification and testing easier and faster ?
Argument : Writing Cleaner classes would usually mean writing more code
This correct because in clean code you have :
1- More descriptive variable names.
2- Uses function and class declarations as a way to add commentary to the code.
3- Ensures SRP, and thus result in a lot of code seperation.
But the gains we made are huge, we have a self-documented code that isn't a source of horror for its maintainers and readers. Testing would be doable and replacing one part by a newly designed web service for example won't be a task that requires months of continuous hard work.
Lastly, what is the most frequent part of the coding process ? It is change and thus you need to design and write your code for change.
Argument : Following Clean Code principles oftens leads to drowning in code design and over-design ?
You can avoid this by following YAGNI (You are not gonna need it) principle.
In simple words,
1- Build the smallest, simplest thing that solves the problem.
2- Improve it.
3- If you found a class/component that gets modified a lot then a redesign/refactoring can be proposed to make change smooth and easy. By making change easy we refer to OCP principle which simply imply that the design should encourage adding features and doing changes as an extension to the current system not as a modification to the current coded part.
4- Iterate :)