Architecture, refactoring or what’s really important

In the life cycle of every project there is a moment when the question of refactoring arises. Engineers want something new, fashionable, and interesting to appear in the project. The business needs to get a new functionality faster and faster. And the project team say they get tired of making changes and need refactoring. Does it sound familiar?

Now before you agree to refactor your system/subsystem, I think you should answer the following questions:

Is it really necessary for you?
What will refactoring give you?
What will be the consequences?
What should be done in order not to use refactoring in the future?
If you do have to rewrite the code, what will your plan be like?

Is it really necessary for you?

Before you start refactoring, you should thoroughly analyze the design with the aid of an automatic tool, such as SonarQube, in order to assess the existing code base. Make measurements related to performance and collect detailed information about points where it can be enhanced.

Then asses how much time engineers spend on supporting the existing solution and implementing new features. The existing system may not be good for extension; data on labor costs can be retrieved from JIRA/Redmine/TeamCity/TFS. It would also be useful to check how the product owner implements changes, or whether the user stories have changed. In that case you will need to refactor the process and procedures of handling Change Requests.

What will refactoring give us, or what is the point?

When deciding on refactoring, it is necessary to agree on what will be done. Try to get a list of concrete “benefits” to be obtained after refactoring. They should be measurable, for example:

Order processing time will be shortened by x minutes
New feature launch time will be reduced by a factor of 2
Refactoring will enable us to do A/B testing, which will lead to more sales
It will help support more clients, and therefore get more orders

At this stage, you should collect benefits that your business customer can comprehend.

What will be consequences, or "It’s not the developer’s fault"

When doing refactoring, it is crucial to understand the consequences that may appear - not only the positive ones. Will you need to conduct regression testing or not? Should you launch localization or performance tests? In a word, you must understand what will be broken if you implement refactoring and what you should check.

To minimize side effects, you should ask the developers after refactoring to conduct unit and automated tests, including integration tests, which might be viewed as some extra work but will add another level of control and remain as some further improvement for the customer :)

To avoid unnecessary overtime for hot fix releases, it would be good to run a complete cycle of regression testing, and conduct a number of exploratory testing sessions. This will help you find some interesting defects :)

Finally, we should understand:

What can be “affected” by refactoring
How will we check the system health
What tests/results will be given as proof that everything is in apparent good order and condition
What recommendations will the programmers give to the quality assurance team
How we can verify that the “old” users are not hurt in any way by the new changes

In the second part of the article we will look at how we can minimize the use of refactoring in the future and how we plan rewriting the code.

Ivan Alyakskin
Software Consultant