DEV Community

Jane
Jane

Posted on

Code reviews 101

Behind every non-interrupting production codes stand a sequence of process called code review. How does code review rule in your team look like?

Hers are some of the criteria to merge new lines of code to a production branch in my team:

  1. There should be at least minimum 2 approvers to verify the code is safe to land on the main branch
  2. Tests must be included to verify that the new adding code won't break anything
  3. Tests coverage percentage, ideally it should be increase rather than decrease. In some special case, it can stay the same
  4. CI/CD pipeline passed - no explanation needed because if it's not green then it won't going in...
  5. One MR/PR one functionality - we will always nitpick about mixing differences features in the same commit or branch
  6. Clean commit message - commit message should explain what the change is about for future traceability
  7. Always rebase from main branch
  8. Add document/README if necessary - by default there should be README in the repo but in case there is new feature in the change, adding more info is best practice

In order for the criteria above to be working, we need good collaboration from reviewers and code assigners. I've listed some of the points that reviewers and coders should keep in mind based on my own experiences.

First of all I think, as a decent reviewer, one should:

  1. Ask questions to clarify any ambiguity
  2. Give comments: if it's good it's encouraging to point it out and if it needs some improvement it should not be overlooked
  3. Site resources: always attach detail reading to help coders learn and broaden their knowledge
  4. Give code suggestion to clarify on the comment: if it seems complicated by writing alone, it's best to give a code suggestion
  5. Always ask for tests/doc if not provided
  6. Review in one-off manner, avoid giving review on the 1st version after the 1st round of change is already applied
  7. Be kind - leave judgemental out of the process and focus on making the code better
  8. Give ETA - if you're requested to review some codes while you're working on other thing, please at least let people know and don't let them hang in there
  9. Clone the code and run locally - if needed, we should try running the code locally to make sure it works as expected

And for the review requester, before asking for code review, make sure to:

  1. include description of what the change is about
  2. pick reviewers that are more likely familiar with the piece of code
  3. attach the MR/PR to the related ticket requirement
  4. specify which part you most would like to request another pairs of eyes
  5. ask back questions if you are not clear with any comments/suggestions
  6. be open to take good suggestions
  7. give reasons to your different point of view

These are all I have so far, feel free to drop yours. Happy coding/reviewing :)

Top comments (0)