How to refactor critical code with a heavy usage in production
By: Mélanie Godard
Tags: Engineering, Monitoring, Legacy Code, Refactoring

How to refactor critical code with a heavy usage in production Mélanie Godard Follow Nov 30 · 6 min read

In this article, you’ll learn how we refactor critical code used daily by millions of users.

Every month, 10 millions of people are planning their day to day health appointments using Doctolib. In order to allow our users to find the right practitioner and book an appointment with them, we have implemented a structure which we call “the booking funnel”. Up until now, we have continuously improved this funnel to handle multiple features (document sharing, patient referral or extra informations).

In the end, this booking funnel was becoming more and more complex to allow all these scenarios to unfold correctly for our millions of users everyday.

Until last year, most of this funnel was coded with a client side view in React, except for one step. For this specific view, we had an enormous piece of code handling every possible use case and redirecting the user to a templated html code developed in slim.

As time passed and the company grew, this view grew as well… in complexity. It became difficult to read and new joiners struggled to grasp this part of the codebase. We also had more and more colleagues experienced in React that were wondering why this view stayed this way.

In an effort to tackle this legacy code, separate the different use-cases into different components and improve the overall experience of our users, we decided to migrate this code into React.

And that’s when our problems started

We started refactoring the code little by little and we were happy with where it was going. But the more we worked on it, the more complex our first pull request was becoming. Several problems appeared:

other teams were working on this view so the code kept changing

we had to handle a lot of complex cases and it was difficult to tackle all of them at once

since we have a huge test suite at Doctolib (around 10 000 tests at the time), changing even a little the UX of this funnel meant adapting a lot of these tests

at the time), changing even a little the UX of this funnel meant adapting a lot of these tests we didn’t want to impact our current users, so it had to be retro-compatible and work even without users refreshing their page

in the end, the pull request was so big that our coworkers were getting very worried

It was time to find a strategy to ensure the migration would happen in a smoother way.

Let’s draw

It is always a good idea to get a visual image of what your code will look like. It’s also a good way for your coworkers to understand what’s going on. Especially when your pull request gets too big too fast.

And that’s what we started with. It was quick, easy and allowed us to merge our pull request quicker.

Two different funnels

As our pull request kept growing, it became obvious we could not tackle everything at once. But at the same time, the features implemented in this view were so intertwined, we could not rewrite them all one by one.

We didn’t want to spend weeks, even months, re-coding the whole view without ever being able to test it on real users.

What we wanted was a first version of a common use case of the booking funnel, so that we could see if it worked in production before iterating on it.

We decided to start with the most common one: allowing someone to simply take an appointment for themselves or for a relative, and to redirect all the others cases to the old funnel.

All we had to do was introduce a completely separate view.

Old view in slim vs new view in ReactJS

For example, if we didn’t implement the custom fields in this version yet, which means that all the people taking an appointment with a practitioner in need of additional information from the patient would see the old view. In the meantime, all the users taking an appointment for another practitioner who does not need these additional informations would see the new view.

This means that our old code would still be present for several months and would still work with all the features already developed at this time.

Feature switch your new version

At Doctolib, when we introduce new features, we often decide to hide it in production until we are sure it’s working properly.

We also have the possibility to show the new feature to a certain percentage of users.

At first, we weren’t very confident so we selected several medical practitioners with only a few appointments taken per day and activated the new funnel for the users booking an appointment from their profile page.

After being reassured by this first test, we activated the feature for 1% of all users, which was already a pretty good chunk of people (as a reminder, around 10 millions of people go through our funnel to take an appointment each month).

of people go through our funnel to take an appointment each month). Then, after fixing a few errors that popped up, we progressively activated it for everyone in a couple of days.

This system is also a good way to quickly hide a feature in case of a suspicious error. We would use it to deactivate the new version from time to time to work on some issues without worrying about blocking our users.

Keep an eye on potential errors

Since we have two completely different views, we can easily track our users with NewRelic to know the number of people using the new or the old version of the booking funnel.

Number of users using the old version (in blue) and the new version (in yellow) of the booking funnel after activating the first iteration of our work

Another example of how this kind of monitoring helped us is that we could easily spot bugs on this view and their severity. If too many users were affected by this bug all we had to do was to switch off the feature or revert the last iteration.

We quickly deactivated the new version when we saw this curve

Have an easy way to know when to remove the old code

As soon as the percentage of people using our new view dropped to 0% (or so, with a margin of error), we could be sure the old code was not used anymore and remove it instantly.

This booking funnel refactoring has not been an easy journey and there were several surprises along the way. Maybe some of the steps we took could help you too:

Have a concrete plan to rollout your refactoring

Monitor the usage and the potential bugs produced by your new code

And most important of all, communicate as much as possible on your progress with the people and teams working on the same scope

Did you like this article? Go subscribe to our tech newsletter for more!