The larger the code change, the harder it is to review. So what happens when we’re doing a code migration? Technically there’s a huge set of changes to make to get the code from its original state into a new form. How do we manage that?
What the What?
A couple of definitions before we get into the detail here.
Firstly, let’s review the idea of reviewing. Some teams prefer not to do code reviews, considering the work of a mob or a pair to be better than an asynchronous peer review. That’s fine, but I would suggest that even a mob or pair should have some mechanism to check their changes before final commit. I don’t just mean test automation, which they should also have, I mean reading the diffs to ensure that there’s no surprise.
Peer review is, in some ways, less powerful than reviewing something yourself. My preference is to review something myself, knowing that someone else will be looking at it. The fact that it will be reviewed by someone else makes me see my own code differently at the diff-reviewing stage. I review my own diffs even on solo projects.
The second definition is a code migration. Let’s assume that sometimes there’s a project that was made in a different version of the technology we use, and we’re about to update it to the latest version. Let’s assume that there’s no half measures here; we’re lifting and shifting in some way shape or form, and the old build can’t be gently evolved to the new world.
Avoiding a Huge Migration Review
Depending on the type of migration, we have a few options for how to make our changes reviewable. The key consideration is whether the review could be understood by a person easily. This means either:
- A small amount of change, which can go quite deep
- Only trivial changes, which are easy to understand without much reading
- Additional of boilerplate, which may be extensive, but can be treated as a boilerplate block – thus avoiding the bootstrap review problem
Here some code migration ideas, optimised for reviewability:
- Ignore buildability, and make a series of thin changes to the code as a whole until it complies with the new standard – each thin change targets one improvement/fix for the new world
- Build the new project from zero and import the old code a piece at a time, fixing as you go
- Do a hybrid migration where the old code is imported as a library to the new platform somehow, and is then rolled across a module at a time with minor changes
Incremental Wins
For reducing risk, increasing teamwork, and making it easy to understand, working in small batches is consistently the best aim.
We can forgive ourselves a batch that has lots of line changes that are, essentially, the same.
Fundamentally, though, the challenge of any big code migration is working out how to slice it into increments so that it can be managed easily and understood at every step of the way.
| Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: The Code Review Problem for Migration Opinions expressed by Java Code Geeks contributors are their own. |
