As the program develops, we will have to rethink earlier decisions and rework certain portions of the code. Code is not static. It needs to evolve.
Rewriting, reworking, and re-architecting code is collectively known as refactoring.
Refactoring.. When should we do that?
Following are some scenarios where we need to refactor our code:
Refactoring is not always easy. We have to go through the existing code and modify it without affecting the functionality. Many developers are reluctant to do this because their code is mostly fragile.
Time is another reason for not refactoring. But the reality is that, if we fail to refactor it now, we might have to spend much more time later for fixing bigger problems.
Refactor Early, Refactor Often
Rewriting, reworking, and re-architecting code is collectively known as refactoring.
Refactoring.. When should we do that?
Following are some scenarios where we need to refactor our code:
- Duplication - when we detect a violation of DRY principle.
- Non-orthogonal design - when we discover that the design can be much more orthogonal.
- Outdated knowledge - when the knowledge about the problem domain increases.
- Performance - when we need a much better performance than existing.
Refactoring is not always easy. We have to go through the existing code and modify it without affecting the functionality. Many developers are reluctant to do this because their code is mostly fragile.
Time is another reason for not refactoring. But the reality is that, if we fail to refactor it now, we might have to spend much more time later for fixing bigger problems.
Refactor Early, Refactor Often
- summary of Refactoring, from The Pragmatic Programmer: from Journeyman to Master
No comments:
Post a Comment