コードレビュー解体

どうもJudaです。
コードレビューがあるので、しっかりと基礎固めをします。
と言っても、まずは既存の解説記事に当たろうと思います。
効率の良いコードレビュー [software]
Effective Code Reviews Without the Pain
レビューの基礎知識
をあげます。

やはり基本的にはコードレビューは、

1. コードの品質の保証
2. 知識の共有/開発者同士の成長促進

が念頭にあります。

また議論としてコードを題材にしているだけであり、それを記述した個人の資質、存在に言及することはよくないことであると注記しています。つまりよくあることであると言っているのです。

またToshiya HASEGAWA氏の意見である、ソースコードを頭から眺めていくことの非効率性についての言及はもっともであると思います。
しかしToshiya HASEGAWA氏の意見に私見を加えるならばペアレビューでの、文法チェックやコーディングルールの遵守の確認は、あまりに機械的な作業であるため、コンパイラやチェッカで調べればよく、人間でなければならない理由はあまりないと考えます。私はペアレビューをもし行う場合には、局所的なロジックの妥当性確認やクラス単体での呼び出し整合性の確認を行うほうがより苦痛（退屈）が少なくなると推察します。

チームレビューでのチェックは、微に入り細に入ったレビューを行うがため、
The developer often feels like it's a bashing session designed to beat out their will. 
（意訳：開発者はコードレビューは彼らの心を打ちのめすために設計された糾弾の打ち合わせのように思っています。）
すべては雰囲気作り次第であるとは言えますが、たやすくそういう場にしてしまうので、参加者すべてがルールを強く守らないといけません。

宿澤経営情報事務所さまの記事では、さまざまなレビューについて簡単にまとめられており、そのなかで挙げられているインスペクションの有用性と落とし穴についても言及されています。この中でも、レビューが個人の資質を糾弾するための記録として利用されるかもしれないという疑心暗鬼のために、自身の資質をPRするために、レビュー自体が活発なものにならない可能性を指摘しています。組織内での政治的な活動の一部が正常なインスペクションを阻害するのです。組織内での政治的な活動のために、協調的教育的な意味合いの近い活動を利用することは本来のレビューの目的を阻害してしまうため、とても強く注意されていますが、やはりそれだけ多く見られる行動であると推察します。

コードレビューの多様な形態やその基本的なルールを勘案すると、

• コードというよりも、そこに記述されているロジックを如何にすれば、特定の目的により合致するようにできるのかを多様な解答の中から提案する場としてレビューがある。
• 個人の資質について言及することは、それ自体がレビューの趣旨に合わず、場の活動を阻害するため、参加者すべてがつよく守るべきルールである。
• 微に入り細に入りコードをレビューすることは、全体的な質を均一にするためには必要かもしれないが、あまりに時間がかかりすぎるため、ここでもカプセル化を推進し、事象の粒度を粗から細に臨機応変にすることが望ましい。
• なぜという問いかけは、その質問自体がコードを記述した個人のみに帰属する問いになるため、絶対にしてはならない。

というのが大枠である。