Google Engineering Practices Documentation を翻訳した
成果物はこちら。
翻訳作業は自作ツール Inalz で行なった。
以下、Google Engineering Practices Documentation の内容から少しポイントを拾ってみる。
現在 google/eng-practices リポジトリにあるのは Google 社内のコードレビューに関するドキュメントで、コードレビューをどうやって行う／受けるべきかを解説している。
その中で一番重要なのはおそらく「コードレビューの基準」のページで、流し読みするだけでも効率的なプロダクトの開発フローが学べる。
https://fujiharuka.github.io/google-eng-practices-ja/ja/review/reviewer/standard.html
その中でコードレビューの「最上位の原則」として取り上げられているのが以下のルールである。
一般に、CL が完璧でなくても、その変更がシステムのコードの全体的な健康状態を改善すると確実にわかれば、レビュアーは CL を積極的に承認すべきである。
CL は changelist (変更リスト) の略で、GitHub でいうところの Pull Request みたいなものと考えればいい。
「コードの健康状態 (code health)」という用語が出てくるが、これはおそらく Google 発の概念で、若干の説明を要する。コードの健康状態とは、コードの保守性、可読性、安定性、単純さといったいわゆるコードの品質を表している。Google の Testing Blog によれば、ソフトウェア工学においてコードの品質にかかわる領域を「health」というアナロジーで呼び始めたのだという。
上記の原則は、開発のスピードとコードの品質のトレードオフの最適な落とし所を表現している。
開発は効率的にスピーディに行わなければならないが、ろくなコードレビューをせずにマージするとコードの品質が下がる。一方でコードの品質を上げるためにコードレビューで重箱の隅をつつくような細かい指摘をし続けてマージをブロックすると、今度は開発のスピードが下がる。
そのトレードオフの落とし所が、「コードの健康状態」を改善するかどうかという観点である。たとえレビュアーの流儀に適った完璧な CL でなくても、「コードの健康状態」を良くする CL であるなら、細かい指摘はいったん置いて承認せよ。
これはどんな開発でも役に立つコードレビューの基準の現実解だと思った。
他にも有益情報が満載なので、ぜひ皆様にも通読していただきたく。
