レビューで最初に見るのは、好みではなく「動くか」「読めるか」

「インデントとif文の書き方についてコメントが3件、肝心のロジックには何もコメントが付かないままapprove」——身に覚えのある人もいるはずです。

自転車置き場の議論

原子力発電所の設計図には誰も口を挟まないのに、自転車置き場の屋根の色には誰もが意見を言う——という比喩があります。簡単に口を出せる論点ほど、議論が集中しやすい。レビューでも同じことが起きます。命名や書式は誰でも指摘できるので先に埋まり、仕様の理解や設計の方向という重い論点にたどり着く前に、レビューが終わってしまうことがあります。

見る順番を決めておく

だから見る順番を先に決めておきます。正しく動くか → 読めるか → 好み、の順です。書式やコーディング規約は、人が見るものではなく本来Linterに任せる領域です。人間が見るべきは、機械が見られないもの——仕様の理解、抜けている考慮、設計の方向です。

好みの指摘は、重さを付けて言う

好みのレベルの指摘をゼロにする必要はありません。ただ、「nit:」のような軽い指摘だと分かる印を付けるだけで、直す順番が相手に伝わります。印がないと、受け手は小さな指摘まで全部「直せ」と受け取り、時間と体力を消耗します。

常駐先での信頼は、こういう積み重ね

レビューでの振る舞いは、名指しで頼られる人が、日常でやっている小さなことと同じ構造です。大きな指摘を的確に出すことよりも先に、指摘の優先順位を分かっている、印をつけて伝える、という日々の小さな配慮が、レビュアーとしての信頼を作ります。

コードレビューで判断が変わる原則は、エンジニアの型の問題集にまとめてあります。