Refactoring: Why do we get into that situation in first place?

Refactoring is a process of modifying the code without changing the software behavior. Re factoring is required to make the design robust and flexible for future code modifications and more importantly increasing the code readability. In lifetime of software most of the times, the code is read than written or modified. More time required in reading/understanding the code than time taken to make the actual changes because modifying the code without understanding it property there lies the risk of introducing the new bugs.

I was just wondering why do we even get into the situation where we've to refactor the code? Well, this is tough question to answer. So my say is that the complexity of the software is directly proportional to the number of developers. While this is the fact, what if we have few developers(4 for example) who are always there to write and own the code and only those modify? Lets say that these four developers have been given the clear instruction that they have to follow all the design principles and guidelines that exist for object oriented languages. Over a period of time do we still get into the situation where we need to refactor the code? 

Before seeing what's the conclusion on above question, let me write some of the essential facts that happen in software life span especially in legacy software.

1. Different developers have different coding styles and different way of thinking this may happen due to developers being in different experience level. The same developers will not be there for ever to own the code. The extra time for correcting(refactoring) the old code is not planned/forgotten while making a fix, adding a new feature or during code reviews, the focus will be on the current issue being resolved than bothering about rest of the code 

2. No one initially designs the systems for better performance and future requirements. As a best practice, the systems are designed only to address the current requirements. And requirements change over the curse of time and you are bound to modify the code to accommodate the new requirements.

3. Sometimes performance comes at the cost of not following certain design guidelines. The straight example is that method calls are costlier but OO design guideline says that methods should be smaller. 

4. Lack of having sufficient unit test cases specially automated unit test cases. Unless the team is following TDD(Test Driven Development), the developers do not bother touching the code which does not solve the current issue.

So the discussion where in you hire expert developers with same experience level who will be writing the code from the scratch and also will be owning the code for future modifications. Does this team write and maintain the good quality code that does not have any code smells? We've not tried this but the opinion of many (with developing experience of more than 10 years) was No. There may come one of the above four aspects on the way and there could many code smells which are resolved by refactoring.

Though its impractical or tough task to have good quality code that follows all the OO design guidelines over a period of time, efforts to improve the code quality are advised. Refactoring can not happen overnight, and hence there we have introduced something called "Continuous refactoring"

The Importance of Code Refactoring in Developing and Maintaining Software Systems

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

Code Refactoring

Refactoring is restructuring existing code. Refactoring is carried out to remove code smells. Refactoring does  NOT fix bugs. Refactoring is done when there are robust unit test cases to test the code. These test cases are executed before and after refactoring the code and test case results must be the same before and after. This ensures there are no bugs introduced due to refactoring.

As a practical example, a software was supporting a protocol and requirements got changed and we wanted to support a second protocol, refactoring was done to extract the source code that stands common for both the protocols and protocol specific code was separated out and common interface was provided. The point is that sometimes refactoring becomes mandatory to incorporate new software requirements. Refactoring is also applied just to improve the code readability, better maintenance and extendability purposes.

1. Some refactors are controversial
2. Some are arguably not improving code quality
3. Refactoring can in fact be counter productive when applied blindly
4. Apply in combination and make sure refactoring is applied in productive manner.

Refactoring Methods

1. Extract Method: If your method is too long and is performing multiple tasks, the code snippet that is doing a unique task that main method name does imply, that code snippet is extracted into a method.
2. Replace temp with query: This is about assigning a query result into a variable and then using that variable, instead the query result can directly be used. This is controversial anyway.
3. Replace type code with state/strategy: You have a type code that affects the behavior of a class, but you cannot use subclassing.
4. Replace conditional with polymorphism : You have a conditional that chooses different behavior depending on the type of an object.
5. Form template method: You have two methods in subclasses that perform similar steps in the same order, yet the steps are different.
6. Replace Magic Numbers with symbolic constant: You have a literal number with a particular meaning