絶対にモテる（チームから）コードレビュー実践編

f:id:tsukahara1991:20211018140302j:plain

こんにちは。エンジニアの塚原（@AkitoTsukahara）です。

今回は弊社の内部資料として使っている「コードレビューの型」を紹介します。

個人的にエンジニアにとって、コードレビューは福利厚生だと思っています。快適な開発現場を共有できるようにコードレビューについて考えていきましょう！

PHPカンファレンス2021で発表させていただいた「【IMO】コードレビューって難しいよね」の内容とほぼ同じものになっております。スライド資料で確認したい方はこちらをご覧ください。

これはなに

M&Aクラウドにおけるコードレビューの型です。 新しく入社されたメンバーに「コードレビューで何をするのか、どのようにしたら良いのか」という共通認識を持ってもらうための資料です。

コードレビューの目的

  • ソフトウェア品質の向上
    • 技術的負債となり得るコードがないかを確認する
      • 技術的負債とは、今後の機能拡張の障壁になりうるもの。いますぐに負債として発現するものでなくても、将来の拡張により負債となることもある
    • そのコードでユーザに今届けるべき価値が実現できているか確認
  • スキルの向上及びナレッジの共有（属人性の排除）
    • 他人のコードを読むことによって学びや発見を得る
    • 開発者同士のコミュニケーションの活発化
    • 担当者の実装レベルの把握と向上（教育的観点）

コードレビューの心構え

  • レビューしたコードを自分事として捉えること
    • チームのコードを育ている意識を忘れない
    • 人のコードもバグったら自分の責任
  • 最初から完璧なコードレビューができなくても大丈夫
    • まずは理解できないコードを無くしていくことを目指す
      • 分からないところは質問してみよう！

コードレビューの手順

f:id:tsukahara1991:20211018125015p:plain
PR→コードレビューのフェーズ

PR→コードレビューのフェーズ

  • 仕様を把握する
  • コードを見て、動きを想像する（想像できない時は先に動かしてみる）
  • 設計に違和感がないか、考慮漏れがないか確認する
  • 実際に動かしてみる
  • エッジケースを洗う
    • 例）登録ステータス、会員ステータスによって動作に不具合が発生しないか
  • セキュリティの問題がないか確認する
  • コードの影響範囲を洗う

コードレビュー→マージのフェーズ

  • 他のレビュアーのサポートをする
  • マージされるように実装や仕様を固めるのをサポートする
  • 本番に入れるまでと入れた後に必要なことを確認する

コードレビューで心掛けること

  • 自分がアプルーブしたコードに責任を持ちましょう。誰かが書いたコードという認識ではなく、チームのコード（資産）として、自分事として認識すること

個人で取り組む工夫

  • システム障害が発生した事象とコードを把握する

    • 実際に不具合が発生してしまったコードからなぜ発生したのか、なぜレビューから漏れてしまったのか振り返りを行って、改善に努めましょう

  • 誰よりも先にコードレビューをする

    • 慣れないうちは後からレビューすると「もう1人が見ているから大丈夫だろう」と意識が働きやすいです。できるだけ先にレビューしましょう
    • 先のレビューで見つけられなかった指摘箇所や考慮漏れがないか確認してみましょう

  • 自分が見ていないPRもチェックする

    • 別チームのPRや過去のPRをチェックしてレビュー経験値を積んでいきましょう
      • レビューコメントにある指摘理由は他の場面でも利用できることがたくさんあります。
      • プロダクトのコードを理解する上で過去のPRを見ておくことはおすすめです

チームで取り組む工夫

チームで効率良く運用できるように蓄積されてきたノウハウです。 下記以外にも効率良くできそうだなと感じることがあれば、メンバーに提案していきましょう。

  • PRテンプレートを利用する
    • GitHubでPRを作成する際に入力項目が自動生成されます。
    • PR前にチェック項目がクリアしていることを確認しましょう
  • 一回のPRサイズは400行を目安に
    • コード量が400行を超えていくと不具合を見つける精度が下がっていきます。大きなPRになる場合は、実装のキリの良いところでPRを分割しましょう。
  • ペアプロでコードレビュー
    • コードレビューをしていると細かい修正のラリーが何度も続いてしまうことがあります。
    • ペアプロで細かい修正はその場で解決してしまいましょう

コードレビューのコツ

  • 400行程度のPRは30 ~ 60分くらいでレビューを済ませよう
    • 1ptタスクで ~30分、3ptタスクで ~60分の目安
  • コード修正をコメントする時は根拠も一緒に記載しましょう
    • 根拠があればレビュイーも修正すべきか判断しやすくなります
    • 後からそのPRを見た人もなぜ修正されたのか経緯を知ることができます
    • レビュイーももらった修正案をそのまま鵜呑みにするのでは無くて、それが適切な形なのか考えながら判断しましょう。もし腑に落ちなければ、相談してみましょう
      • 即修正ではなくて、もらったアイデアを取り込む位のスタンスで
  • LGTMには素敵な画像を贈りましょう

PRを出す時のコツ

  • レビュアーがレビューしやすい様にサポート
    • コードの中で実装の肝となる部分にGitHub上でコメントを追加する
    • 実装で最適解なのか不安な部分はコメントでわかる様にする
    • 事前知識を必要とする実装の場合は、レビュー前に解説する
      • 例）口頭で実装の全体像を説明する→その後にレビューもらう

採用やってます

弊社ではエンジニアの採用を行なっています。 スタートアップ企業でのWeb開発に興味のある方は、ぜひカジュアルにご応募ください🤝

www.wantedly.com

画像引用元: Unsplash