コードレビューって、時間のムダなの！？

まずはレビューするポイントを絞ることが大切だと思う。

コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい議論が紛糾しているのは「コードのインデント幅が違う」とか「return が省略されてる。俺は return があったほうが好み」とか「その場合は字下げをした方が綺麗にみえるんでは」とか、そんな些末なことばかりである、ということが多い。必ず一度は通る道である。

些末なコードレビュー - naoyaのはてなダイアリー

ぼくが思うに、この話の本質はそこじゃなくて、はてなブログのjsのコメント見たら「はてなブログって大丈夫なの！？」って思えてしまって、じゃあ技術的にはどうなのよ！？ってとこだと思うんだけど、そこは置いといて、個人的に興味がある「コードレビュー」に関して私の思うところを書きます :)

そもそも

コードレビューを嫌うプログラマが多いのです。曰く「こんなの時間のムダだ」「そんなことしてる時間があったらテストした方がいい」云々。

なぜそんなことになるか。引用先の記事にあるように、コードレビューでイヤな思いをすることが多いからだ。「些細なこと」のようなスタイルに関わることは、コーディング規約でもない限り、あまりこだわる必要はないと思うけど、こんな指摘をされることがある。

• これだと遅いから、もっと速いこっちのアルゴリズムにしよう
• もっとシンプルな実装にすべき
• ここはこういう構成にした方が分かりやすい
• 名前が分かりにくい

ソフトウェアは考え方をアルゴリズムで体現したものなので、それに対する指摘も主観的なものになりやすい。「こっちの方がいい」「これは好きじゃない」といった、レビューを受ける人から見ればどうでもいいと思えるようなことを指摘されると、プログラマは萎えてくるわけです。

細かい指摘ばかりしてくる人。単に細かいとこしか見てないって場合もあるけど、実際は「コードレビューを依頼されたから、とにかく何か指摘しなきゃ」って使命感から来ることが多い。本人悪気はないんだけどね。

そういったことに疲弊した結果、コードレビューがキライになり、「コードレビューなんていらない」っていう印象をプログラマは持ってしまっているように思う。

ところで

コードレビューって何だろう！？Wikipediaによると、コードレビューとは

コードレビュー（英: Code review）は、ソフトウェア開発工程で見過ごされた誤りを検出・修正するためにソースコードの体系的な検査（査読）を行うこと。ソフトウェア品質を高めると同時に開発スキルの向上を図ることができる。

コードレビュー - Wikipedia

とある。そうだね。でもこれって、すごく曖昧で範囲が広すぎると思わない！？

コードレビューってどんな風に依頼する？コード渡して「これレビューして」ってだけ言ってる、ってことない！？もしそんな依頼をしておいて「細かい指摘ばかりでイヤになる」と言うのであれば、それはレビューを依頼する側にも原因があると思う。

最初に「こういう観点でレビューしてね」って言っておけば、それ以外の指摘をされても「それはこのレビューのスコープ外」とか「後で直す」とか言える。モデレーターを置くのもいいかもしれない。

あと機械が出来ることは出来るだけ機械にさせた方がいいと思う。コーディング規約や静的解析はいろいろツールがあるよね。不思議なもので、細かいことでも機械に指摘されたことは割りと受け入れやすいんだよな。「なんでこんな指摘しちゃうの（笑）」ってなることはあったにしてもね :)

ぼくが思うに

レビューするポイントを絞るというのが、コードレビューを効果的に行うために最も大切なことだと思う。

広範囲にいろいろな問題点を探そうとすると、簡単に見つかるレベルのバグしか検出できないだろう。後になって大問題になるようなバグは大抵コードの奥底に潜んでいる。そもそも全部直せるわけじゃない。どうせ優先度の高い順に直していくことにしかならない。

だったら最初からレビューすべきポイントを絞って深く掘り下げて見た方がいい。性能。拡張性。堅牢性。セキュリティの脆弱性。等々。プロジェクトにとって、何が重要なのか、をまず見極めるべきじゃないだろうか。

その方が、何よりプログラマのコードレビューに対するモチベーションが上がるんじゃないかと思うよ :)