第二部：技術領域への案内
コードレビュー
はじめに
Wantedly では書いたコードについて GitHub Pull Request を通じてレビューを受けることが必須になっています。 コードレビューは仕事を前に進めるためには避けては通れないという事実がある一方で、コードレビューで多くの時間を使ってしまっているケースや完全に作業が止まってしまっているケースを見ることがままあります。
コードレビューはレビューイ(reviewee)からレビュアー(reviewer)への仕事の依頼です。 レビュアーがパフォーマンス高く効率的にレビューができるか否かは仕事を依頼するレビューイの段取りにかかっています。
本記事ではコードレビューをより良いものにするための3つのポイントを紹介します。
- レビューの目的を明確にする
- Pull Request がなぜ必要なのかを辿れるようにする
- 小さい単位で Pull Request を作る
レビューの目的を明確にする
レビュアーに何を見てほしいのか、予め気になっているところがあればレビューを依頼する際に一言添えておくとレビュアーがレビューしやすいです。
- 大まかに設計方針と実装が妥当そうかどうか
- コードの書き方が正しいか、よりよい書き方がないか
- 不安なところの相談
また、設計自体に不安があればコードを書き始める前にレビュアー(となる予定の人)と適切にコミュニケーションを取って事前に設計方針を固めておきましょう。 ほとんどコードを書いてしまってからレビューの段階で設計自体の問題点を指摘された、かつそれがコードを書く前でも問題を指摘可能だった場合に大きく無駄を生んでしまいます。
コミュニケーションの方法は次の2つを上手く使い分けると良いです。
- 同期コミュニケーション (対面でのミーティング, Google Meet)
- 非同期コミュニケーション (GitHub issue, Slack)
(Kick Off など一番最初に設計に取り掛かる際は同期コミュニケーションが良さそうです)
Pull Request がなぜ必要なのかを辿れるようにする
経緯を全ての人が知っているとは限らないので Why の部分は必ず書きましょう。issue のリンクを貼っておくことで十分な場合もあります。後でこの PR を見た人が Why の部分を理解できるようにしておくことが重要です。 (それはレビュアーかもしれないし、後にバグを直す人かもしれないし、半年後の自分かもしれない)
小さい単位で Pull Request を作る
可能な限り小さい機能単位で Pull Request を作ったほうが素早く質の高いレビューを受けられることが多いです。 機能が大きく、随時 master にマージできない場合は先に Feature ブランチを作ってそこから小さいPull Request を重ねていくと良いでしょう。
- 📝 Feature PR の例: wantedly/yashima-ios#8843
- 📝 yashima-ios では diff が 500行を超えると bot が warning を出してくれる
レビュー負荷が下がった例を紹介
- まず機能の全体観をレビュアーになる予定のメンバーに共有
- 小さい単位で機能毎に PR を作り個別でレビュー依頼
- API から取得したデータをローカルのストレージに永続化
- ローカルのストレージに永続化された連絡先データを TableView で表示
- アプリ起動時: API に差分があるかを問い合わせて、差分があればローカルのストレージを更新
- 連絡帳同期機能: 有効になっていれば、OS 標準の連絡帳アプリと差分を取り、差分があれば API に差分を更新するリクエストを投げる
話を聞きに行きたい
もっと知りたい
最終更新 2mo ago