Lets first see what exactly is refactoring. In simple words, refactoring is a process of modifying the existing code in order to get benefits in terms of say code readability, maintainability, re usability etc without changing the software behavior. The refactoring is also done to remove 'Code Smells'. The examples of refactoring are extract a piece of code into a method (Extract Method), Extract class, move a field etc. The IDEs such Eclipse, NetBeans have menu options to aid the developer do code refactoring. In Eclipse IDE, the refactoring option will have actions such as Move, Change Method Signature, Extract Method, Extract local variable, Extract constant etc.
When is refactoring done? Our customers never bother whether we do code refactoring or not. Refactoring is not customers' cup of coffee. Customers may not even understand what the refactoring is and how that's going add value. Well, if refactoring is not required for our customers, then why do refactoring? Customer is not going to give a penny for this activity. Well then, its the developers or the software design owners or software architects who are going to decide whether or not refactoring needs to be performed. As the definition says, the refactoring is done to get certain benefits. These benefits may not be consumable immediately but over the long term. Refactoring is typically done to legacy code if that code can be reused to address different business requirements. So the legacy code as is may not be reusable, but may be the code needs to be tweaked a little in order to make it reusable. If no code can be reused then code is developed from scratch, no refactoring at all.
Refactoring activity is performed when the modifying the existing code to incorporate new features or enhancements becomes difficult; may be because of the initial bad design.
No one wants to 'over' design the systems and the systems get designed to address the known requirements at the time of designing and software requirements do change and/or new requirements do arise at later point of time. We have two options, redesign the system from the scratch or see if the existing code can be reused by little modifications.
So I can say that a well designed software code never needs refactoring. Because the code is already readable, reusable, extensible and there are no code smells.
The important aspect in refactoring is that there has to be strong base of automated test cases. As we know the behavior of the software must not be changed due to refactoring activity. How can we make sure this happens? Its not practical to test the code modifications manually since its a time consuming process and every time a code is modified we need to make sure the change does not cause any issues in dependent software modules (impacts). So before we start refactoring, we need to have strong mechanism to constantly check software behavior.
Refactoring helps developers number of ways. Refactored code is easy to understand, the developer reading the code can enjoy doing it. Refactoring helps find software bugs. Refactoring improves the design, etc. In my experience, a software product code which is say around 5 years old usually requires refactoring because there were several changes done to the code by different developers, new features have been added, several bugs have been fixed. Some methods look really bulky which eventually becomes not unit testable at all which is risk factor.
If we know that new product enhancements are coming up in feature, it makes sense to revisit the code refactor it to make it ready to accept new changes with less effort
When is refactoring done? Our customers never bother whether we do code refactoring or not. Refactoring is not customers' cup of coffee. Customers may not even understand what the refactoring is and how that's going add value. Well, if refactoring is not required for our customers, then why do refactoring? Customer is not going to give a penny for this activity. Well then, its the developers or the software design owners or software architects who are going to decide whether or not refactoring needs to be performed. As the definition says, the refactoring is done to get certain benefits. These benefits may not be consumable immediately but over the long term. Refactoring is typically done to legacy code if that code can be reused to address different business requirements. So the legacy code as is may not be reusable, but may be the code needs to be tweaked a little in order to make it reusable. If no code can be reused then code is developed from scratch, no refactoring at all.
Refactoring activity is performed when the modifying the existing code to incorporate new features or enhancements becomes difficult; may be because of the initial bad design.
No one wants to 'over' design the systems and the systems get designed to address the known requirements at the time of designing and software requirements do change and/or new requirements do arise at later point of time. We have two options, redesign the system from the scratch or see if the existing code can be reused by little modifications.
So I can say that a well designed software code never needs refactoring. Because the code is already readable, reusable, extensible and there are no code smells.
The important aspect in refactoring is that there has to be strong base of automated test cases. As we know the behavior of the software must not be changed due to refactoring activity. How can we make sure this happens? Its not practical to test the code modifications manually since its a time consuming process and every time a code is modified we need to make sure the change does not cause any issues in dependent software modules (impacts). So before we start refactoring, we need to have strong mechanism to constantly check software behavior.
Refactoring helps developers number of ways. Refactored code is easy to understand, the developer reading the code can enjoy doing it. Refactoring helps find software bugs. Refactoring improves the design, etc. In my experience, a software product code which is say around 5 years old usually requires refactoring because there were several changes done to the code by different developers, new features have been added, several bugs have been fixed. Some methods look really bulky which eventually becomes not unit testable at all which is risk factor.
If we know that new product enhancements are coming up in feature, it makes sense to revisit the code refactor it to make it ready to accept new changes with less effort
No comments:
Post a Comment