Google Engineering Practices で 一石六鳥のコードレビュー

2021/07/30 (Fri) 社内 LT 会で発表した内容です。

### 参考資料
Google Engineering Practices Documentation | eng-practices
Google エンジニアリング・プラクティス ドキュメント | eng-practices
GitHubがすばやく安全にリリースを行うためにどのようにフィーチャーフラグを利用しているか
コードレビューは少人数の優秀な人にまかせると | 外資就活相談室

Transcript

1. Google Engineering Practices で 一石六鳥のコードレビュー 2021/07/30 Takuya Yamaguchi (@no_clock)
2. @no_clock たいぷらいた～ 近況： 『ゼロからの OS 自作入門』 1 と i の typo で一日溶けた https://book.mynavi.jp/ec/products/detail/id=121220 ゼロからのOS自作入門 | マイナビブックス
3. コードレビュー、 遅くなってる？
4. マージされるまでの日数 1 日 → 3 日（中央値） コードレビューが遅くなった 参考：チームのスタイル • コードレビュー必須 • 誰がレビューしてもよい • 空いている人がやる
5. レビューが遅いと… 指標への影響 リリースまでのリードタイム増 気持ちへの影響 嬉しくない （詳細は一石六鳥のネタバレになるので省略）
6. 「コードレビュー、 　速くしたいですね」 「…」
7. どうしてレビューできないんだろう？ 「…」（遠い目） 自分のタスクで 手一杯 動機がない レビューできる 自信がない メンバ増えたし 誰かがしてくれる （傍観者効果？）
8. ……と、とりあえず、 打開策を見いださねば…！
9. Google Engineering Practices 「長年育ててきたベストプラクティスの集まり」 • コードレビューガイド のみ公開 • 非公式日本語訳あり • CC BY 3.0 ライセンス Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/
10. Google Engineering Practices コードレビューガイドライン Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ レビュイー • 最適なレビュアー を選ぶ • 変更は小さくする • よい説明を書く レビュアー • すぐに見るか代打を提案 (最大 1 営業日) • 基準に従ってレビュー • よいところは褒める コードレビューの基準 （あとで紹介）
11. 小さく始める • 「やってみたい人で試してみる」 気軽な感じでスタート
12. 手間なく始める • 説明用のテンプレートを用意 (GitLab Description templates) • 定期的にボットにメンションしてもらった
13. やってみて 2 週間、 振り返りアンケート
14. 振り返りアンケート結果 好評 🎉 徐々に広がり 今はチーム全員で やっています 🎉 レビューの速度が上がっていい感じ！ 自分の変更に対する理解が深まる 変更のサイズが小さくなったので レビューしやすい 変更の説明めちゃくちゃ助かる
15. 実は、 一石六鳥のコードレビュー！
16. Google Engineering Practices コードレビューガイドライン（再掲） Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ レビュイー • 最適なレビュアー を選ぶ • 変更は小さくする • よい説明を書く レビュアー • すぐに見るか代打を提案 (最大 1 営業日) • 基準に従ってレビュー • よいところは褒める コードレビューの基準 （あとで紹介）
17. レビュイー • 最適なレビュアー を選ぶ • 変更は小さくする • よい説明を書く Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ レビュアー • すぐに見るか代打を提案 (最大 1 営業日) • 基準に従ってレビュー • よいところは褒める コードレビューの基準 （あとで紹介） マージまでの日数 (中央値) 3 日 → 0.6 日 🎉 一鳥目: レビューが速くなるなった
18. Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ 強調は発表者による。 二鳥目: 不満が減る 例）厳しすぎる…とか 今更その指摘は…とか レビュイー • 最適なレビュアー を選ぶ • 変更は小さくする • よい説明を書く レビュアー • すぐに見るか代打を提案 (最大 1 営業日) • 基準に従ってレビュー • よいところは褒める コードレビューの基準 （あとで紹介） “コードレビューのプロ セスに関する不満の大 部分は、実際にはレ ビューのプロセスをす みやかに行うことに よって解消されます。”
19. Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ 三鳥目: レビュアーの負担が減る レビュイー • 最適なレビュアー を選ぶ • 変更は小さくする • よい説明を書く レビュアー • すぐに見るか代打を提案 (最大 1 営業日) • 基準に従ってレビュー • よいところは褒める コードレビューの基準 （あとで紹介） レビュー（レビュアー）の ハードルや負担が下がる ※レビュイーに 　負担してもらう
20. 四鳥目: レビューの質が上がる [1] GitHubがすばやく安全にリリースを行うためにどのようにフィーチャーフラグを利用しているか https://www.infoq.com/jp/news/2021/06/github-feature-flags/ レビュイー • 最適なレビュアー を選ぶ • 変更は小さくする • よい説明を書く レビュアー • すぐに見るか代打を提案 (最大 1 営業日) • 基準に従ってレビュー • よいところは褒める コードレビューの基準 （あとで紹介） 1 回あたり 400 行を超えると 欠陥発見率が低下する [1]
21. 五鳥目: よりよい設計を促進する Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ 強調は発表者による。 レビュイー • 最適なレビュアー を選ぶ • 変更は小さくする • よい説明を書く レビュアー • すぐに見るか代打を提案 (最大 1 営業日) • 基準に従ってレビュー • よいところは褒める コードレビューの基準 （あとで紹介） “適切なサイズとは、1つの 自己完結した変更のこと” • それなりの設計が必要 • 最初の小さな変更なら 方針転換も容易 （巨大な変更だと全部書き直し）
22. 六鳥目: 内部品質が上がる Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ 強調は発表者による。 コードレビューの基準 （ここで紹介） “システムのコードの健全性を劣化させるような CL は、決して受け入れてはなりません。” “システムのコード全体の健全性を具体的に向上 させる状態に一度でも達したならば、 (略) レビュアは承認を賛成しなければならない。”
23. 一石六鳥、 Win-Win-Win 🥳 レビュイー すぐレビュー してもらえる 不満が減る レビュアー 負担が増えると 思いきや減る ハードルが下がる プロダクト リードタイムが短くなる 内部品質が上がる
24. 一石六鳥、 Win-Win-Win 🥳 レビュイー すぐレビュー してもらえる 不満が減る レビュアー 負担が増えると 思いきや減る ハードルが下がる プロダクト リードタイムが短くなる 内部品質が上がる の予定 チームが手応えを 感じるのはまだ先。 俺たちの戦いは これからだ！
25. Q. 最適なレビュアー、 偏りませんか？
26. 強調は発表者による。 コードレビューは少人数の優秀な人にまかせると | 外資就活相談室 https://gaishishukatsu.com/box/questions/26840/?focusAnswer=23833 あえて偏らせて 文化醸成や スキル向上を 加速させる ただし大変 あくまで一時的 Q. 最適なレビュアー、偏りませんか？ A. 偏ってもいい。
27. Q. 続きそうですか？
28. Q. 続きそうですか？ A. 分かりません。 • 1 ヶ月くらい続いている • 失敗してもナイストライくらいの気持ち
29. 参考 • Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ • Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ • GitHubがすばやく安全にリリースを行うためにどのようにフィーチャーフラグを利用しているか https://www.infoq.com/jp/news/2021/06/github-feature-flags/ • コードレビューは少人数の優秀な人にまかせると | 外資就活相談室 https://gaishishukatsu.com/box/questions/26840/?focusAnswer=23833