Google Engineering Practices で 一石六鳥のコードレビュー 2021/07/30 Takuya Yamaguchi (@no_clock)

@no_clock たいぷらいた～ 近況： 『ゼロからの OS 自作入門』 1 と i の typo で一日溶けた https://book.mynavi.jp/ec/products/detail/id=121220 ゼロからのOS自作入門 | マイナビブックス

コードレビュー、 遅くなってる？

マージされるまでの日数 1 日 → 3 日（中央値） コードレビューが遅くなった 参考：チームのスタイル ● コードレビュー必須 ● 誰がレビューしてもよい ● 空いている人がやる

レビューが遅いと… 指標への影響 リリースまでのリードタイム増 気持ちへの影響 嬉しくない （詳細は一石六鳥のネタバレになるので省略）

「コードレビュー、 　速くしたいですね」 「…」

どうしてレビューできないんだろう？ 「…」（遠い目） 自分のタスクで 手一杯 動機がない レビューできる 自信がない メンバ増えたし 誰かがしてくれる （傍観者効果？）

……と、とりあえず、 打開策を見いださねば…！

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/

Google Engineering Practices コードレビューガイドライン Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ レビュイー ● 最適なレビュアー を選ぶ ● 変更は小さくする ● よい説明を書く レビュアー ● すぐに見るか代打を提案 (最大 1 営業日) ● 基準に従ってレビュー ● よいところは褒める コードレビューの基準 （あとで紹介）

小さく始める ● 「やってみたい人で試してみる」 気軽な感じでスタート

手間なく始める ● 説明用のテンプレートを用意 (GitLab Description templates) ● 定期的にボットにメンションしてもらった

やってみて 2 週間、 振り返りアンケート

振り返りアンケート結果 好評 🎉 徐々に広がり 今はチーム全員で やっています 🎉 レビューの速度が上がっていい感じ！ 自分の変更に対する理解が深まる 変更のサイズが小さくなったので レビューしやすい 変更の説明めちゃくちゃ助かる

実は、 一石六鳥のコードレビュー！

Google Engineering Practices コードレビューガイドライン（再掲） Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ レビュイー ● 最適なレビュアー を選ぶ ● 変更は小さくする ● よい説明を書く レビュアー ● すぐに見るか代打を提案 (最大 1 営業日) ● 基準に従ってレビュー ● よいところは褒める コードレビューの基準 （あとで紹介）

レビュイー ● 最適なレビュアー を選ぶ ● 変更は小さくする ● よい説明を書く Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ レビュアー ● すぐに見るか代打を提案 (最大 1 営業日) ● 基準に従ってレビュー ● よいところは褒める コードレビューの基準 （あとで紹介） マージまでの日数 (中央値) 3 日 → 0.6 日 🎉 一鳥目: レビューが速くなるなった

Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ 強調は発表者による。 二鳥目: 不満が減る 例）厳しすぎる…とか 今更その指摘は…とか レビュイー ● 最適なレビュアー を選ぶ ● 変更は小さくする ● よい説明を書く レビュアー ● すぐに見るか代打を提案 (最大 1 営業日) ● 基準に従ってレビュー ● よいところは褒める コードレビューの基準 （あとで紹介） “コードレビューのプロ セスに関する不満の大 部分は、実際にはレ ビューのプロセスをす みやかに行うことに よって解消されます。”

Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ 三鳥目: レビュアーの負担が減る レビュイー ● 最適なレビュアー を選ぶ ● 変更は小さくする ● よい説明を書く レビュアー ● すぐに見るか代打を提案 (最大 1 営業日) ● 基準に従ってレビュー ● よいところは褒める コードレビューの基準 （あとで紹介） レビュー（レビュアー）の ハードルや負担が下がる ※レビュイーに 　負担してもらう

四鳥目: レビューの質が上がる [1] GitHubがすばやく安全にリリースを行うためにどのようにフィーチャーフラグを利用しているか https://www.infoq.com/jp/news/2021/06/github-feature-flags/ レビュイー ● 最適なレビュアー を選ぶ ● 変更は小さくする ● よい説明を書く レビュアー ● すぐに見るか代打を提案 (最大 1 営業日) ● 基準に従ってレビュー ● よいところは褒める コードレビューの基準 （あとで紹介） 1 回あたり 400 行を超えると 欠陥発見率が低下する [1]

五鳥目: よりよい設計を促進する Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ 強調は発表者による。 レビュイー ● 最適なレビュアー を選ぶ ● 変更は小さくする ● よい説明を書く レビュアー ● すぐに見るか代打を提案 (最大 1 営業日) ● 基準に従ってレビュー ● よいところは褒める コードレビューの基準 （あとで紹介） “適切なサイズとは、1つの 自己完結した変更のこと” ● それなりの設計が必要 ● 最初の小さな変更なら 方針転換も容易 （巨大な変更だと全部書き直し）

六鳥目: 内部品質が上がる Google Engineering Practices Documentation | eng-practices https://google.github.io/eng-practices/ Google エンジニアリング・プラクティス ドキュメント | eng-practices https://shuuji3.xyz/eng-practices/ 強調は発表者による。 コードレビューの基準 （ここで紹介） “システムのコードの健全性を劣化させるような CL は、決して受け入れてはなりません。” “システムのコード全体の健全性を具体的に向上 させる状態に一度でも達したならば、 (略) レビュアは承認を賛成しなければならない。”

一石六鳥、 Win-Win-Win 🥳 レビュイー すぐレビュー してもらえる 不満が減る レビュアー 負担が増えると 思いきや減る ハードルが下がる プロダクト リードタイムが短くなる 内部品質が上がる

一石六鳥、 Win-Win-Win 🥳 レビュイー すぐレビュー してもらえる 不満が減る レビュアー 負担が増えると 思いきや減る ハードルが下がる プロダクト リードタイムが短くなる 内部品質が上がる の予定 チームが手応えを 感じるのはまだ先。 俺たちの戦いは これからだ！

Q. 最適なレビュアー、 偏りませんか？

強調は発表者による。 コードレビューは少人数の優秀な人にまかせると | 外資就活相談室 https://gaishishukatsu.com/box/questions/26840/?focusAnswer=23833 あえて偏らせて 文化醸成や スキル向上を 加速させる ただし大変 あくまで一時的 Q. 最適なレビュアー、偏りませんか？ A. 偏ってもいい。

Q. 続きそうですか？

Q. 続きそうですか？ A. 分かりません。 ● 1 ヶ月くらい続いている ● 失敗してもナイストライくらいの気持ち

参考 ● 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