第86条
コードの健全性を上げるなら承認する
すべての変更に完璧を求めるとレビューが遅くなり、遅いレビューはコードベースを良くするどころか悪くする。
心得
完璧でなくても、良くなるなら通す
どうするか
変更によってコードが以前より確実に健全になるなら、自分なら違う書き方をしたとしても承認する。磨き込みの指摘には「Nit:」を付けて、作者が見送れるようにする。ブロックするのはコードを悪くする点だけにする。緊急時を除き、全体としてコードの健全性を確実に悪くする変更は承認しない。
なぜ起きるか
完璧なコードは存在しない。あるのは、より良いコードだけだ。完璧を待つレビュアーは誰も届かない基準にこだわり、その間、変更は止まったままになる。作者は作業をまとめて大きな変更にするようになり、そのぶんレビューは粗くなる。あるいは直すべきコードに手を出さなくなり、変更に含まれていたはずの改善はいつまでも入らない。差し引きで良くなるかを基準にすれば、マージのたびにコードベースは正しい方向へ進み、それでいてレビュアーは悪くする変更を拒める。
当てはまらなくなるとき
割れ窓理論：差し引きで改善だからと小さな欠点を一つずつ通していくと、見過ごされた欠点だらけのコードベースが残る。一つ通すたびに、次も通しやすくなる。
出典
Google「The Standard of Code Review」『Google Engineering Practices Documentation』(2019)。"favor approving a CL once it is in a state where it definitely improves the overall code health"、"there is no such thing as 'perfect' code—there is only better code"、任意の指摘に付ける「Nit:」の出典。
原典を読む引用するとき
Hammurabi『第86条 コードの健全性を上げるなら承認する』 https://kanywst.github.io/hammurabi/ja/laws/code-health-standard/
BibTeX
@misc{hammurabi-code-health-standard,
title = {コードの健全性を上げるなら承認する},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 86},
url = {https://kanywst.github.io/hammurabi/ja/laws/code-health-standard/}
}関連する法則
- 29ボーイスカウトの規則コードが劣化するのは、片付けが、めったに実施されないリファクタリングに先送りされがちだからだ。
- 57割れ窓理論放置された小さな乱れは、基準は守らなくてよいという合図になり、さらに乱れを呼びやすい。
- 05パーキンソンの凡俗法則議論は重要な部分ではなく、誰でも口を出せる簡単な部分に集中する。
- 100ブレイントラスト (権限を持たない助言)オーナーを覆せる人からの意見は、活かされるより先に防御の対象になる。修正を強制できない仲間なら率直に言えるし、オーナーも落ち着いて聞ける。
- 103小さな変更レビューに出す変更が大きいほど、一行ずつは丁寧に読まれなくなる。欠陥はすり抜け、最初に見てもらうまでの待ちも長くなる。