概要

本記事はチーム開発においてレビューを導入するにあたり気をつけたりしていることを主に自分向けに整理している記事となります。
良さそうな情報や今後の経験含め随時追記していくことになると思います。

レビューツール

最近はだいたいソースコード管理はGitHubを使用している会社、プロジェクト、チームが多いので、基本的にはGitHubでPull request(以下、PRと記載)にて行うことが多いかなと個人的には感じています。

コードの書き方を否定するだけでは、レビューイからすると責められてる気がする可能性があるので、代替案を提示してやんわり修正を促すようにしています。

例）　XXXという関数名はYYYとする方が役割が分かりやすくて良いかも

機能要件を満たしていないコードはもちろん修正必須ですが、パフォーマンスが多少悪いとか可読性が多少悪いなどは開発期限次第で修正内容をIssueとして残して一旦パスさせるとか判断させる材料を提示するようにしています。

例) XXXの部分はネストが多すぎて可読性が低いので、別関数に切り出すなど対応した方が良いかもですが、挙動は問題ないので一旦Issueに残して後で対応もありかも

見た感じ大丈夫そう という意味で、これはPull requestをApproveするときによく使っています。
Looks Good To Me の略ですね。

ご参考までに という意味で、コメントする際にソースを提示する時などによく使っています。
For Your Information の略です。

私個人の意見としては という意味で、自分ではこう記述するなぁと伝える時に使っています。
In My Opinion の略です。

nitpick (細かいことを指摘する) の短縮で 細かいことですが という意味です。
些細な指摘をする時に使ってます。

これは 誤字 という意味で、自分は誤字・脱字を指摘する際によく使っています。

個人的にはレビュー文化は良いものと思っています。
ただその手法によっては、レビューアとレビューイの関係性が悪くなってしまったり、それを意識して指摘できなくなってしまうなどもあるので、お互いをリスペクトして快適なレビューを皆がしてくれると良いなぁ。