How we use github/scientist23 March 2016
Only a few weeks ago, the amazing folks at Github released the first version of Scientist (more about the gem in their blog) Scientist helps developers to refactor big chunks of code. More than refactor, it helps with rewriting parts of code, because sometimes a local refactor is not enough.
Scientist equips a legacy codebase with the ability of executing different branches of code (branches that perform the same actions) and comparing the current implementation with the new implementation. The behaviour will not change because the current branch is being executed and performing its tasks as usual, while the new rewritten part is executed with all the benefits of a production environment.
Lately, as we explained in past posts, we are fighting with our legacy code using different techniques, and Scientist quickly joined our toolbox. We have been using more rudimentary approaches for executing different branches of code without impacting the application so we started using Scientist straight away and enjoying all the benefits. Let’s introduce a couple of cases where it has been very useful to us.
Case #1: Changing the search engine.
At one point last year our search engine was not able to cope with the volume of data and our mates using the internal applications were experiencing turbulences when the system was under heavy load. This is a typical scenario where this technique specially shines since we can not refactor a search engine, we have to replace it.
The gem provides an abstraction for managing the experiment actions such enabling the experiment, publishing results after the execution, rescuing potential exceptions, etc. Here we have created an experiment to test the new search engine.
And it is inevitable to change the production code, although the changes are small.
use block contains the current code, the code that works and what the
science block returns. The
try block is the candidate (it could run more than one candidate). No matter what happens inside the experiment, the main execution will not be impacted.
Case #2: Replacing the user management system.
Also because of scaling issues, we have some challenges segregating users of different domains. Having all users in the same
Users table creates an important issue when the volume increases only for some sets of users.
The implementation is very similar to the search engine one. There is an alternative execution branch that makes a remote call to a new service called
Identity, where we are organizing the users now. The experiment logs the exception into a file when a given user is not authorized in the new service although it is authorized in the current system. That way we can browse all the exceptions later and fix them.
We are still finishing these systems migrations and with the help of this gem and some other techniques, like the mikado method, it is much easier to work with a legacy codebase. We have noticed that as we continue learning techniques to deal with legacy code, it becomes easier, safer and faster to modify old code, and the line between legacy and greenfield becomes blurry.
Miguel Angel Fernández. Developer at Flywire.