On-Ramp To Code Review

Pull requests visualization

In the recent years, code review has been vital process in the web development. Down the rode, people encounter many issues and obstacles which end up this process being a bottleneck. Personally i came to realize most of the problems are process related and not people.

Go to the first principle

Do a small survey within your development team and ask them to rate the following statements as “I Agree” or “ I Don’t Agree”:

  1. I believe in sharing knowledge
  2. We should write as much reusable code as possible
  3. Every one in the team should collaborate to produce quality code
  4. Code ownership enables you to move fast in the short run but it increases dependance in the long run
  5. All developers within a team should follow some sort of code authoring guidelines
  6. Constructive discussions improve code quality
  7. Feedback is a gift, it helps me improve my professional skills

Mindset matteres

You’ve probably read a lot about the mindset and attitude when it comes to code review.

Collaborate with the team to come up with common practices when authoring pull requests as well as code reviewing.

When code reviewing…

  1. Focus on the code not the person
  2. Complement you comment with a concrete example to avoid infinite conversations
  3. Be considerate with your language when writing comments.
  4. If you feel you need to talk to the author about a pice of code, do it and avoid long conversation threads in the review tool
  5. If you have different opinion about something, choose different forum to express that, specially if it’s not must fix thing
  6. Do not rush in pressing the decline button, instead, collaborate with the author to fix the issues you create.
  7. … come up with more

When creating a pull request…

  1. Be considerate when it comes to the size of the pull request you are creating. Avoid large pull requests at all costs
  2. Split tasks to as small pull requests as possible
  3. Solve one specific problem
  4. Avoid unnecessary refactoring to reduce the noise. If you have to do it, do it in separate pull requests concerning only that
  5. Follow the authoring guidelines you agreed on with the rest of the team to avoid bouncing pull requests
  6. Document your code, even better, write descriptive code
  7. Install linters and syntax checkers during development to avoid getting unnecessary comments
  8. Make sure all tests pass, in addition, cover the code you produce with new tests
  9. Avoid “TODO” and “FIXME” comments as much as possible, those usually bring a lot of discussions. Write a sufficient comment when it can’t be avoided
  10. Write some comments in the code review tool about how your code can be tested

Come up with “Code Review Manifesto”

Collaborate with the team to come up with “Code Review Manifesto” where you write down all the points you have agreed on.

Iterate

Never trust a process, Instead, evaluate and iterate. Tackle issues and problems along the way and as quick as possible, to avoid the snow ball effect.

Conclusion

Getting affirmation from your team members about the above points is vital step towards proposing your code review process, It makes sure that everyone is on the same page.

It is very important that people feel the need for a code review process, and make sure you never copy processes from other places, instead, develop your own