コードレビューでレビュアーが気をつける事

最近うちのチームでコードレビューがいい感じに運用できています。
「コードレビューってこうするんですね」ってメンバーに言われてとても嬉しかったので調子にのってコードレビューで気を付けている事を書いてみます。
■レビュアーが気をつける事
1.解決方法は1つだけではない
レビューする前に仕様が判っている事がほとんど。
そうするとレビュアーはコード見る前に自分の中で勝手にコードを予想してしまう。
これがあまり良くない。自分の予想と違うとついつい誘導したくなる。そこはぐっと我慢。
レビュアーの予想が正しいとは限らない。
2.断定せずに質問を投げかけるようにする
なぜその様にコードを書いたのか理由を聞く様にする。
その際「なぜ?」の使い方を気をつける。レビューを受ける人は責められている様に感じてしまう。
3.褒める
褒めなれてないと難しい。慣れてないと照れくさい。
でもこれができないと良い点がシェアできないのでがんばる。
4.議論の対象はあくまでもコード
これは耳タコ。でも難しい。
問題はコードにあり開発者ではない。わかってるんだけどね。
最近は上手くいっているかも。
5.間違い探し
スペルミスやコーディング規約に沿っていない(軽い逸脱)ぐらいなら許す。
そんなことをコードレビューで指摘するのは勿体無い。もっと見るべき点がある。
6.誰が優れたプログラマーかコンテスト
気をつけないとほんとに陥り易い。自分の自慢は呑み会にでもとっておく。
コードレビューには必要ではない。
途中まで優先度順に書いてみたんだけど見直したら順番付けられなくなった。
どれも重要でどれも難しい。

不具合は基本的に原因療法で

不具合見つけて短絡的に対症療法を選ぶ人が多すぎて困りものです。
不具合を見つけた場合、症状ではなく原因に目を向け対応するべきです。
しかしある時点までいった場合に、原因に対して対応することが難しくなることがあります。
それはコストとリスクの問題です。

ツールの制限によるリスクを考える

プログラマの生産性について個人差があるのは周知の事実で
仮に5人のプログラマが所属するチームがあったとする。
そこに所属する凄いプログラマが全体の50%以上の業務をこなしたと想定すると
Aさん:50%(凄い)
Bさん:20%(普通)
Cさん:15%(普通)
Dさん:10%(しょぼい、新人)
Eさん:5%(ダメな人)
合計:100%
だったとする。
ここでチームのリーダが全体の生産性を上げたい為に
エディタ「hoge editor」を各プログラマに利用する旨を通達した場合何が起こるかというと、普通な人は当たり前にエディタ「hoge editor」を利用していたので生産性は向上しない。
しょぼい人or新人は利用することにより5%の生産性が向上した。
ダメな人は何を使ってもダメなので生産性はそのままだとすると
以下の様になる。