How Cross-Review Brings Order to Development

Image for post
Image for post

When a developer writes code for hours without a break, unnoticed mistakes will appear that can ruin the program in the end. Because of this, development without a proper ongoing review process can hardly be imagined.

One of the most useful and efficient ways to organize the review process is to use cross-review. While this review method might be unfamiliar to some people, it is popular among development teams around the world.

Here we’ll explain how this model helps development and why it has become so well-known.

What is it?

To put it simply, cross-review is a technique where all the members of the team check each other’s code before it passes on to testing and then to release. Organizing the review process in this way helps the team speed up their development and helps them communicate with each other more comfortably.

One of the best features of cross-review is that it’s not necessarily conducted only between developers at different levels, like junior and senior, but also between peers. For example, a developer might write a bit of code, but due to tiredness, headache, or a bad mood they could miss out on something important or not consider alternative ways of implementation. In this situation, there’s no need to bother a senior developer. A simple side view from a colleague would be enough. A combination of reviews between peers and tech leads provides the best result, creating a final version of the product with as few bugs as possible.

GitFlow

GitFlow is a branching model that is focused on project release. It was created by Vincent Driessen and has attracted a lot of attention because of its collaborative and scaling capabilities. This review model provides a strong framework for managing product development.

GitFlow consists of several branches in the Git versioning system.

Image for post
Image for post

Why is this branching needed? Well, let’s imagine a situation: The client decides to change the color of the “Try again” button in their trivia game from purple to green. A developer creates a Feature branch, where they implement the requested changes. They then review the code, making sure that the new version won’t break anything in the rest of the app, merge this Feature branch with the Develop branch, and when all the changes have been reviewed one more time, the new version appears on the Master branch.

At the very same time, another developer changes the app’s background or the number of answers in another Feature branch. This piece of code goes through the same process of merging and review, so that no code excludes another. All the possible Feature branches — one for each particular change in the code — form the Develop branch of a product, which, in turn, creates a version ready for release.

How the review is organized

A long time ago things worked like this: Developers would work together on the same piece of code at the same time. One person would change it one way, and the second another way. This created conflicts in the code that crashed the program. In this environment, each developer had to shout across the whole office for their colleagues not to touch the same file that they were working on.

With GitFlow everything has changed. Merging and reviewing in this system are organized with the help of pull requests. A pull request is a request from a developer to merge changes into a superior branch (Feature to Develop or Develop to Master).

Now it looks like this: A developer writes 100 lines of code and sends them to the senior developer. They review it, and if everything is okay, the changes are merged in the upper branch. If the code has bugs or there are lines that must be rewritten, the reviewer explains what’s wrong and asks the developer to make the needed fixes. When the corrections are done, another pull request is sent, and if there are no new mistakes and the code works properly, the changes are merged into the Develop or Master branch.

Every team has its own unique way of implementing GitFlow, since it depends on many factors, from the team’s size to the product’s specifications. Nevertheless, if the team sticks to this way of code review, it helps them avoid a lot of misunderstandings and conflicts.

Why use it?

To organize the review process and to bring order to development!

With the help of cross-review and GitFlow, development becomes much more coordinated. Everyone on the team knows what’s happening on the project at the moment, what their tasks are, and what are the deadlines for each one of them.

GitFlow also helps with implementation of other important features:

Final thoughts

Development is a complex process that is not immune to mistakes. A proper review process is the best way to minimize the number of mistakes, and GitFlow helps the team accomplish that.

Originally published at https://yellow.systems.

Written by

A team of engineers writing about web & mobile applications, here’s how we think (https://yellow.systems/blog) and live (www.instagram.com/yellow.systems/)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store