Googleのコードレビューガイドラインを会社で輪読会したのですが、仕事にも役立てる所が多かったです。良かった点や、輪読会で話に出たことをまとめました。
Googleのコードレビューガイドラインとは？
Googleのコードレビューのプロセスや、ポリシーについて書かれています。
コードレビューの仕方、CL(プルリクエストだと思ってもらえれば良い)作成者のガイドで、2つのドキュメントに分かれています。
コードレビューの仕方
シンプルが大事
コードでも設計でもシンプルになることを意識する。新しく覚えたからとか、コードをカッコよく書きたくて、難しく書こうとしない。
オーバーエンジニアリングはしない。
コードにコメントを書く
「何をしているか」というは、よほど複雑じゃない限りコードを読めばわかりますが、どうしてこのような処理にしていたかは、読んだ人にはわからないです。特にコードレビューをした時、理由を聞かれたりした場合は、コードに「なぜ」を書くようにした方がいいです。
新規開発時は、コメントを書かかず、シンプルで読みやすいコードを書くことを意識した方がいいですが、バグフィックスで特殊な修正を入れた場合はコードにコメントしてあげると良いでしょう。
プルリクの良いところを褒めよう
プルリクで良いところがあったら積極的に開発者に伝えよう。
いきなり細かい部分を褒めるのは難しいので、開発を完了してくれた所から始めるのが良い。
レビューの仕方
- 変更を広く眺める。使用設計について問題ないか確認をする。
- プルリクの主要部分(ビジネスロジック部分)を調べる。主要部分に設計上の重大な問題がある場合はすぐに伝える。
- プルリクの残りを適切な順序で見る。
コードレビューは極力優先して作業をする。
テストコードを先に読んだりすると、効果的な場合がある。
レビューコメントの書き方
- 人格否定はしない。主語を開発者にしない。
- 修正するのは基本的に開発者側に任せるが、軽微な修正はレビューアでもして良い。
- 丁寧な言葉を使い、コードを良くするための指摘をする
CL作成者のガイド
CLの書き方
何が変更され、なぜ変更されたのかを説明する。
書き方は新規、バグフィックスなどの変更の場合で以下のように分かれます。
新規の場合
タイトル：どういう機能を追加したかを記載
一行目：タイトルと同じく、どういう機能を追加したかを記載
二行目以降：実装するときに作った資料のリンク、実装の確認してもらいたい所、実装の理由を記載
バグフィックスなどの変更
タイトル：課題、発生した事象について記載
一行目：修正した内容の要約を記載
二行目以降：背景、原因を詳しく記載
CLを小さくする
CLを小さくすることでコンフリクトの修正が最小限になって開発者にとっても良いですし、レビューをしやすくなるのでレビュー側にもメリットがあります。大きなCLになったら分割をすることを考えましょう。目安として１CLにつき、修正100行(テストコードを除いて)くらいにしましょう。
レビューコメントの対応の仕方
個人の人格へのコメントとしては受け取らない
コードレビューを受けたことない人は割と、指摘を受けると自分が責められている思いがちです。あくまでコードを良くするための指摘だという意識を持つことが大事です。
コードを明確にする
コードレビュー時のやり取りで、大切な部分をコードのコメントに追記する。
何が最良なのか開発者自身に考えてほしい
一番コードについて知っているのは、コードを書いた開発者側なので、指摘をそのまま直すのではなく、何が最良なのかを考えて、修正する。
参考
まとめ
Gooleのドキュメントからプルリクの作成や、レビューの仕方を学びました。
今まで、周りのやり方を見よう見まねでやってきた所ではあったのですが、明確にチームとしてのルールができて良かったと思いました。
これを読んで、一人で読むよりメンバー全員で輪読会するのも良いなと思えた方がいましたら、ぜひ輪読会についても記事を書いているのでそちらを読んで頂けたらと思います。
【おすすめ記事のリンク】
コメント