During the last few years, I work on different technologies and different projects
They are mostly time crunch projects and people are not giving attention to what they are writing. Due to this over the period of time codebase become the mud ball and every buddy will try to keep away their hands from it.
Those who are interested to read this post must have faced this issue in their carrier and cursed the developers who wrote that shit. But you must not forget somebody will curse you what you will write today.
So In this post, I will share some learning which I got from my past experience.
I am mostly talking about what is refactoring and why it is important in the long run
in the software development process.
The post is a little long but I am sure, it is worth reading.
As we are programmers we have two types of audiences for our code.
1.Computer 2. Programmers like you and me.
Everybody knows the famous quote from Martin Fowler.”Every fool can write code which can understand the computer. The programmer can write the code which can understand human.”
Refactoring helps to move from the first line to the second from the above quote :).
As a shoshin(empty) mind, I am thinking about refactoring, what is refactoring? why should I do refactoring? When should do and when should not?
What needs to keep in mind when we do refactoring?
Let’s go through the outside-in approach.
What is refactoring (Noun)? When a change is made to the internal structure of the software (program) to make it easier to understand and modify without changing the observable behavior that's called refactoring
Why should we go for refactoring?
Over the period of time software rots or decay due to
Duplication Excess coupling Hacks Technical debt. Basically, technical debt is the sum of duplication, excess coupling, and Hacks. We see technical debt in more detail further. These are the most important reason to push ourselves to do refactoring.
Lets. talk about the advantages of refactoring
- Refactoring improves the code quality.
- Refactoring prevents maintenance.
- Refactoring helps to improve the Design and try to evolve in the right direction.
- It improves the readability and allows us to understand the code more easily.
- Refactoring reveals defects that are most missed by QA people.
- Refactoring helps us to identify the flaws in the system.
- It helps to Program faster.
How do we understand the Technical debt? Read the below statement carefully and think about it it has deep meaning.
“*Shipping first-time code is like going into debt. A little debt speeds development as long as paid promptly with refactoring.
The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt, then the entire organization will be brought under the debt load of unconsolidated of implementation*”. --By Word Cunningham
Not refactoring will cost the entire organization under debt in terms of time, delivery, and client trust
Technical debt slows down customer responsiveness over time as the system is getting larger and more complex.
Small changes will get more expensive because of its need to interact more correctly with the existing functionality of the system.
As shown in fig , technical debt increases the curve upward which increase the cost of change
When should do Refactoring?.
If we have an existing system full of technical debt so should we take a period of the month to clean up probably this is not a good approach to do it, Because the customer does not get any benefit during this period.
Take an example we have a restaurant which has a fully messed up kitchen then should we close for the week and do the cleaning?, probably not because there is a potential loss of business and What reason should we give to a customer for this closing time so rather should keep cleanliness as part of the process.
So Question come, when should we do refactoring?
As part of TDD, we should have to follow the red-green-refactor. So TDD is the best approach to make the system with a good maintainable design. This caused you pain with the design when working with the system goes for refactoring. While fixing the bug. It gives the flow of the system which can give an opportunity to improve the system. Refactoring is part of code review.
When shouldn’t go for refactoring?
When massive technical debt like technical bankruptcy, rewrite the application When the current code doesn’t work. If we have an immediate deadline. then this scenario you should better avoid refactoring.
Martin Fowler stated that ”Other than when you are very close to the deadline, however, you should not put of refactoring because you haven’t got time, Experience with the several projects has shown that about of refactoring result in increasing the productivity. Not having enough time usually sign of you need to do refactoring”
I must say you get the importance of refactoring. Now let's talk about what should we keep in mind while doing the refactoring.
1. Keep it simple Try to avoid being clever to keep it simple. Avoid too much complexity.
2. Keep it dry Wherever possible avoid duplication Follow don’t repeat yourself principle
3. Make it Expressive Make sure what code try to accomplish
Ex. Replace comments with good naming conventions and intention reviling program structure which is also called self-documenting code.
4. Reduce Overall code Try to eliminate code wherever possible but make sure that it doesn’t result from a cryptic one.
5. Separation of concerns Try to follow the SOLID principles. Solid stand for S- Single Responsibility principle O- Open Close Principle L- Lisco Substitution Principle I- Interface segregation principle D- Dependency inversion Principle.
I will talk about the solid on some other day because it is a big topic to talk about. I will post it in the upcoming post.
The appropriate level of abreaction Don’t mingle high-level concerns like business rules with low-level concerns like data protocol.
follow Kent Beck's rules for a simple design.
- Code must run with all the tests pass successfully.
- Contains no duplication
- Express all the ideas that the author wants to express
- Minimize the classes and methods.
- Last but not least “Boy scout rule”. Leave your code better than it found. So over the time system will get much better.
I hope you learn something from this post and appreciate my efforts :) Thanks for reading