Architecture, refactoring or what’s really important. Part 2

In the first part of the article we looked at whether refactoring is good for you, what if offers as well as the consequences. Let’s continue our discussion.

What you can do to avoid refactoring in the future, or “Do it well to make it good”

Managers often ask if it is ever possible to develop a bug-free system. Of course it is, but it takes much more time. I have been involved in software development for years, and noticed that in most cases the development goes in an evolutionary way, and if you look at the history of development of an OS from a leading manufacturer, you will see that only every second product becomes successful.

One way or another, you can’t avoid errors but can control their number by taking certain steps, such as:

Use unit and automated testing
Implement BDD
Make features smaller, introduce and publish modifications of a smaller size, thereby simplifying the system
Do refactoring :) of a smaller size, on a regular basis, like daily housecleaning
Demand responsibility for the system under development from the team
Provide access to a changed/new feature to a limited number of stakeholders, not all at once, which will help identify problems much earlier
Start using unified architecture approaches to decrease the diversity of technical solutions
Introduce and adjust the procedure of technical supervision before creating a new feature or making modifications, conduct an architecture review and solutions monitoring, record results and collect recommendations
Introduce complexity and code quality metrics, and monitor these metrics

From my personal experience I know that one can’t avoid refactoring but can reduce the damage from it by introducing the above mentioned steps.

If you do have to rewrite the code, what plan will you have? “Announce the whole list of actions”.

Once you have received permission for refactoring, you should ask the team to provide:

A list of actions to be done, and a list of concrete metrics to be improved
An architecture proposal/draft, what must be achieved
A performance time schedule
A list of risks
Risk management tactics
A plan in case you are unable to complete the refactoring; yes, there should be a plan in case everything fails

I want to emphasize that the team should do refactoring so that it can be implemented in the system even in incomplete form without affecting the system. In that case, engineers will do their job in a more responsible way.

Some more recommendations on refactoring:

Divide the code into separate layers
Follow the architecture
Try to write components/systems in a compact way and make them interchangeable
Decrease the coupling of systems
Write as many tests as possible
Aim at a system coupling in accordance with common “protocols/interfaces.”

P.S.

This article may seem to sound commonplace, but I have often seen engineers who became enthusiastic about refactoring and failed to make anything of value. I am not against refactoring, I am all for making it successful. If a release failed due to long-drawn refactoring, it would be more and more difficult to ask for another refactoring. It would be better to complete the first small refactoring, prove the consistency of this procedure, gain the customer’s confidence, and then it will be much easier to obtain permissions for further steps.

A long journey starts from a small step, and the system’s modernization starts from small wins with simple and understandable improvements.

Ivan Alyakskin
Software Consultant