Refactoring Databases: Strategies to minimise risks

What is database refactoring for? What are the risks involved and how can we avoid them? Is it really beneficial to our systems?

Cameron Raw, software craftsperson at Codurance, answered these questions in a session in which he also presented several risk mitigation strategies, along with examples and recommendations that you can start applying in your development team.

Benefits of database refactoring

The reasons for refactoring databases can be very similar to the reasons for refactoring application code.

• Improving database performance 
• Reducing complexity
• Adding functionality
• Removing technical debt

Risks of database refactoring

As great as the benefits of refactoring are, teams must be very careful with the great risk it poses when done incorrectly as it could lead to errors such as:

• Data loss. Especially depending on the industry and associated legal risks, such as in the health sector.
• Application features throw error.
• Performance issues.
• System downtime. 
• Incomplete refactor. If you have inconsistent states throughout the database, functionality problems will occur.

How to get the benefits and avoid the risks

Database refactoring is a major operation involving both technical and non-technical teams, and Cameron explained that it is essential to have a clear plan of action focused on both the business and technical areas.

The business-focused action plan consists of constant communication with stakeholders so that they understand the risks involved in the project, the steps to be taken, the skills required, the deadlines, etc.

At the same time, dialogue and planning is also valuable for the development team to unify the process to be followed and to determine multiple variables such as KPIs, deadlines, practices to be used, etc.

Tips for a business-focused action plan

• Constant communication with stakeholders.
• Understand the best moment to carry out the refactoring (in order to have the least impact on the usual operations).
• Define clearly and precisely what we expect from refactoring and what we would consider a successful one.

Tips for a technical-focused action plan 

• Know the current state of your database. Ascertain a clear idea of what the baseline is with regards to metrics.
• Spend a lot of time planning and testing recovery processes in case the worst happens.
• Have a robust testing strategy in place to be able to judge more accurately whether things are working as expected.

The importance of testing

Before refactoring, teams must ensure that they have a solid testing strategy that will give them confidence throughout the refactoring process and keep in constant contact with the quality assurance (QA) team, as they know how best to inspect our system as changes are applied.

Testing, like in any refactoring, is paramount in ensuring we still have our desired behaviour from the system.

- Cameron Raw, software craftsperson at Codurance

Automated tests can have an added complexity to them if moving through an iterative refactoring, but it is important to remember that by really harnessing the power of modern testing pipelines, we can produce thorough, creative solutions for testing that will result in us feeling secure in our database refactoring.

Final recommendations

Refactoring databases is certainly not a simple or short process, but if you maintain a good communication flow and a strategy where all parties are on the same page and aligned, the task will be easier to manage. Cameron offers some final tips to keep in mind:

• Constant communication with all stakeholders, relevant development team members and QA.
• Get a good baseline of how the database currently performs so we can compare accurately throughout the process.
• Testing strategy, testing strategy, testing strategy!
  
  

If you want to check more blogs about methodologies, programming languages and team management, visit our Insights. Also check our next events and join us!