スラッシュドット・ジャパン

「こういうコードが恥ずかしいコードである」
という価値観について、上級技術者間で意識統一がなされていればね。

ようするにコードレビューと言うのは、大学の研究室で言う輪講とかと同じなんです。
コードをよりよいものにする、と言うのも目的の一つですが、コードを組んだ人のレベルアップを図る、という目的もある。

十分な人数の、良く判っているプログラマがいるならばペアプログラミングも良いでしょう。でもペアを組んで回れるほどレベルの高い人がいなかったら?
「教授と助教授と助手の目の前で発表させる」
しかないじゃないですか。

もちろん、この作業は「教授や助教授や助手」の時間を食います。もしあまりにも多くの時間を食うのであれば可能性は次の３つのどれか。

1. 初心者が多すぎる。そのため、「教授や助教授や助手」の時間をフルに使っても、全部など到底見切れない。コードの品質は悪いままである。
2. 初心者が少なすぎる。コードの品質は最初から高く、いくら見ても時間の無駄である
3. 「教授や助教授や助手」のレベルに到達した技術者が実はいない。なので見当違いな所を見ていたり、全員が同じ間違いを犯していていくらレビューしても品質は向上しない

UIレベルのテストで問題がたくさん出てくるのですから 2 である可能性は低いですね。

1 かどうかは、レビューを受ける人とレビューをする人の人口比率を調査する必要があります。
基本的に初心者と判りきっている人に、全コードレビューに参加させるのは得策ではありません。もちろん、良いコードを読むのは重要ですが、自分が組んでいる部分と全く関係の無いコードの、しかも最初のバージョンのレビューに参加しても得られるものは少ないでしょう。それよりも「直せ」と言われた部分を直す事に時間をかけるべきです。
逆に全てのレビューに「教授・助教授・助手」レベルの人たちは参加する必要があります。実質的にコードの質を向上させているのはこの人たちですから。この人たちの時間がレビューに取られる、というならば、この人たちはコーディングをするべきではないのです。それでも足りないなら、プロジェクト全体の人数が多すぎる、と言う事です。

3 … えー、3かどうかは NDA を結んだ外部のプログラマを何人か雇って、彼らのコードレビューを受けるべきだと思います。それまで発見された問題とかなり違う問題点がいくつも発見されるようならば、 3 の状態である可能性は非常に高いです。

> 1. 初心者が多すぎる。そのため、「教授や助教授や助手」の時間をフルに使っても、全部など到底見切れない。コードの品質は悪いままである。
> 2. 初心者が少なすぎる。コードの品質は最初から高く、いくら見ても時間の無駄である
> 3. 「教授や助教授や助手」のレベルに到達した技術者が実はいない。なので見当違いな所を見ていたり、全員が同じ間違いを犯していていくらレビューしても品質は向上しない

結論：ほとんどの日本のIT企業においては、コードレビューは時間の無駄である。

通常は１＆３。運が良ければ１だけのこともある。