Wantedly Engineering Handbook
🎧 Podcast
🍿 YouTube
🛋 Blog
💬 Twitter
検索…
Wantedly Engineering Handbook
まえがき
第一部:開発チームへの案内
技術とアーキテクチャ
プロダクト概要(未執筆)
開発チームの構造
コミュニケーションの全体
ドキュメンテーション(未執筆)
カレンダー
障害対応の心構え
第二部:技術領域への案内
System
Application
Infrastructure
Data
開発プロセス
Git の慣習
ポストモーテムの取り組み
プロダクトの課題発見及び解決
ソフトウェアデザインの基礎
コードレビュー
i18n(未執筆)
開発ツール
おわりに
ロードマップ(未執筆)
Handbook の書き方
コントリビューター
付録
社内用語集
主要なGitHubレポジトリのリスト
今後の挑戦・未解決イシュー
プロダクト開発組織のバリュー
採用についての考え方
GitBook
上で動作しています
コードレビュー
はじめに
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 に差分を更新するリクエストを投げる
話を聞きに行きたい
Slack:
#engineering
もっと知りたい
コードレビューの際に気をつけること - Qiita
コードレビュー開発者ガイド | google-eng-practices-ja
前
ソフトウェアデザインの基礎
次
i18n(未執筆)
最終更新
7mo ago
リンクのコピー
目次
はじめに
レビューの目的を明確にする
Pull Request がなぜ必要なのかを辿れるようにする
小さい単位で Pull Request を作る
レビュー負荷が下がった例を紹介