Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • はじめに
  • レビューの目的を明確にする
  • Pull Request がなぜ必要なのかを辿れるようにする
  • 小さい単位で Pull Request を作る
  • レビュー負荷が下がった例を紹介

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. 開発プロセス

コードレビュー

はじめに

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 を作ったほうが素早く質の高いレビューを受けられることが多いです。 適切なまとまりを考えて、小さい Pull Request を出していくと良いでしょう。

  • 📝 Feature PR の例: wantedly/yashima-ios#8843

  • 📝 yashima-ios では diff が 500行を超えると bot が warning を出してくれる

レビュー負荷が下がった例を紹介

  • まず機能の全体観をレビュアーになる予定のメンバーに共有

  • 小さい単位で機能毎に PR を作り個別でレビュー依頼

    • API から取得したデータをローカルのストレージに永続化

    • ローカルのストレージに永続化された連絡先データを TableView で表示

    • アプリ起動時: API に差分があるかを問い合わせて、差分があればローカルのストレージを更新

    • 連絡帳同期機能: 有効になっていれば、OS 標準の連絡帳アプリと差分を取り、差分があれば API に差分を更新するリクエストを投げる

話を聞きに行きたい

もっと知りたい

前へソフトウェアデザインの基礎次へコーディング規約

最終更新 2 年前

役に立ちましたか?

Slack:

連絡先一覧のリプレース
#engineering
コードレビューの際に気をつけること - Qiita
コードレビュー開発者ガイド | google-eng-practices-ja