Source code review guideline

Here are guideline of source code review in Scuti.

Purposes & merits of source code review

Basically the purpose of source code review is to improve software quality and prevent to increase technical debt in vain. And it's also important to prevent the situation that only specific developer can developer certain modules and the others can't.

Merits for reviewers

Can improve our source code quality.
Can know techniques from the other programmers.

Merits for reviewees

Can improve our source code quality.
Can get the third party point of view.
Can share the responsibility with other programmers.

Prerequisites before source code review

All programmers must complete and pass unit test by themselves.
All programmers must run & pass code sniffer tool.

Workflow of source code review

  1. [Reviewee] After a developer finishes developing a feature, git push to a feature branch.
  2. [Reviewee]  Create pull-request on Github from its feature branch to develop branch.
  3. [Reviewee]  Share the link of pull-request with the other developers on Slack.
  4. [Reviewer] Leave comments to DISCUSS for better code.
  5. [Reviewee]  Modify codes with following comments.

View points reviewers need to POINT OUT

  • Codes which are clearly wrong logic.
  • Codes which clearly don't follow coding conventions.
  • Codes which clearly don't follow requirements.
  • No test code.
  • Hard coding without defining const.

View points reviewers need to DISCUSS

  • Optimum implementation? (module separation, class design and so on)
  • Class name, Method name, variable name are easy to understand for you and optimum?
  • Length of methods is not too long?
  • Depth of nest is not too deep?
  • To redundant codes?
  • Enough test cases?
  • Optimum error handling?
  • Beautiful and clean code for you?

For better review

  • Add the reason why you think so, why you leave its comments.
    ex) "Can you use 'accessToken' for this variable because it's much easier for me to understand the meaning of it."
  • Not only point out but also suggest.
    ex) This code is too long. I think only this code is enough "return $this->getAccessToken();".
  • Try to use emoji (Pictograph).
  • Do not blame developer themselves but discuss about CODE.
    bad example) "Why can't you understand this level of programming?".
If you liked this article

Let's subscribe the updates of Scuti!
Share on Google Plus

About Tomohide Kakeya

This is a short description in the author block about the author. You edit it by entering text in the "Biographical Info" field in the user admin panel.
    Blogger Comment
    Facebook Comment


Post a Comment