言いたいことはタイトルの通りです。
コードレビューをつらいと思う人がいるなんて自分には考えもしてなかったので、この記事には驚かされました。指摘を人格否定と思いがちな人がいるのか、人格否定かのような指摘をする人がいるのか、その両方かは分かりませんが、つらいですね。
プログラマである自分にとって、結果という変わらないものではなく、創意工夫を見せることができるコードを見てもらえる場所って一番の見せ場じゃないですか。プロのスポーツ選手だって成績という数字も大事だけれど、いかに試合でファンを魅了できるかも大事だと思うんですよ。だったら、プロのグラマーである我々も品質とか効率とかの数字だけでなく、レビューという最高のステージでレビュアを魅了させてこそだと思うんです。特に、難しいプログラムを任されるようになってからは、いかに難しい仕様を分かりやすくコードに落とし込むことができるかに最大限に頭を使ったものです。
動けば良いだけの個人プログラマと、顧客の要求仕様に対してバグのないプログラムを提供する職業プログラマの一番の違いって、コードレビューがあるかないかだと思うんですよ。そのコードレビューについて思っていることを書いてみようと思いました。
コードレビューはコードの責任をレビュアに転嫁する作業
レビュー後にバグが見つかったらそれはもうレビュアの責任だ。納品後のバグはＰＭの責任。だから、もしレビュー後の試験でバグを見つけることができたら「ありがとう」と凄く感謝されてきたし、レビュアになった自分も「見つけてくれてありがとう」って何度も言ってきた。「上流工程のバグは、下流工程で増幅する」なんて言うように、できるだけ早く見つけた方が最終的に仕事量が減るものである。後工程になればなるほど、手戻りが増え、お客様への報告に時間がとられ、再発防止で今後の作業が増える。そうならないよう受け止めるのがレビュアだ。プログラマは作るもの、レビュアは保証するもの。個人的には、お互いに90点を取ることで二人でクロスで見ることで99点（(1-(1-0.9)^2)*100）を取れるのが共同作業だと思っているけれど、責任はレビュアに移行するものだと思う。
コードはコンパイラが解読するものではなく、人が読むもの
バグのないコードを書くためのたった一つの秘訣は可読性の高いコードを書くこと。これは以前も書いたけれど、可読性というのはコンピュータに読ませるためではなく人に読ませるための可読性。人に読んでもらうことを念頭に書くだけで、全然違うものになると思う。バグを出さないためにはどうするかを考えたら、自分でバグを作らないことではなく自分とレビュアでバグを取ることを考えるし、今後維持管理していることを考えたら第三者でも分かるコードでないといけないと思う。そうなると可読性が第一だ。可読性が高くなればバグがあったらすぐに気づくものだし、気づかないってことは可読性が低いってことだと思う。つまり、コードレビューをやるということは人に読まれることを前提に書くものとなる。バグを見つけるのが人間なのだから、人間が読むコードを書かなくてはいけない。自分が書いたコードが自分によって読みやすいものであることは当然なのだから、自分以外の誰が読んでも分かりやすいコードを書くように意識が変わってくるだろう。
まとめ
プログラマってどんな時に成長するのでしょう。勉強会や研修、技術系のブログなどあるが、基本的には能動的にスキルアップの意識がないとなかなかできないことであり、（こんなエントリにたどり着いてしまった人は別として）多くの人がプライベートな時間を潰してまではやっていないと思っている。そのため、自ら動かないメンバーのスキルアップのためには開発サイクルの中に成長する工程が必要となり、コードレビューがそれにあたると思っている。どう考えてそう作ったかを伝え、それについてどう思うかを聞くことができ、レビュアからは自分ならどうするかを教えてもらえ、それに対する自分の考えを伝える。いわゆる感想戦のようなものだろう。それを成立させるには、その意識を事前に共有しておかねばならないと思うが、それさえできていればコードレビュー以上に成長できる場はないのではないでしょうか。
良いコードレビューで、良い人生を。
バグのないプログラムを大量生産していく開発サイクルの中に、成長の場があるのです。
ソフトリサーチセンター
売り上げランキング: 63,496
