photo by sebastian_bergmann
コードレビューについて勉強してみた@HIROCASTERでございませう。
コードレビューについて古い資料をあさり、学んで、経験と照らし合わして、書いていきたいと思います。
今回は、これからコードレビューを実施していきたいという人達に向けて、コードレビューをする動機と、どこからやるべきなのかという視点を考えます。
ソフトウェア開発において、多くの問題はコードを起因にして起きます。そのため、多くのプログラマー達がコードレビューをしようと考えます。これは良くある会社の光景ではないかと思います。そして、コードレビューをする出発点となります。
医者が患者に苦悩を伴ってもらわないと、大病が治らないのと同じように、プログラマーが苦悩を伴ってもらわないと、ソフトウェアの大きなバグや致命傷は治りません。
よって、コードレビューは
苦悩が最大と思われるところからレビューを始めよ。
といわれます。
重圧が大きいのでは？
これからコードレビューをやろうとしている人達にとっては、これは重圧が大きいのではないでしょうか？
そのとおりだと思います。ですが、だからこそ、用心して、努力して、継続して、コードレビューをしなければ解決に至りませんし、次のステージには迎えません。
プログラミング過程のごく一部をレビューしたからといって、数十年たっても複雑なソフトウェア開発がコードレビューで、すべてを解決するわけがありません。
コードレビューは魔法ではないのです。
コードレビューで得られるものは大きい
コード・レビューから得られる結果は、多くの人々がたやすく認識できるものになる公算がきわめて大きい
レビューを実施した人達が、レビューによって、残した結果は何だったのかを明らかにすることを惜しまないなら、レビューの理念は支持されるるようになるはずです。
コードレビューによって、残した結果とは？
例えば、
コード・レビューを行う以前に、保守において、一行を変更する作業のうち55%が最初の実行で誤りとなったことが立証できたため、たとえささいな変更でも、保守におけるコード・レビューを行おうという強い動機となった。
そして、コード・レビューを制定した後には、保守による変更のうち最初の実行での誤りは2%以下になった。さらに、コード・レビューを実施する以前には20%に達しなかったすべての保守時の変更の正しさが、実施後には、最初から95%以上となった。そして、エラーがあったとしても、以前に比べればそれほど重大なものでなくなってきた。
こういった事実を明らかにする努力をする必要があります。そうすれば、コードレビューをするということに支持を得られるでしょう。ゆくゆくはソフトウェアを開発する組織として、素晴らしい文化を構築していきます。
ですが、いきなりバグを計測や統計するようなことからはじめると、コードレビューは定着しません。
[ソースコードレビューという貴重な機会と時間の価値を最大化させるためのポイントを教えます！:title=次回は、コードレビューが定着していない組織が、どのようにコードレビューを始めるべきか]というお話です。
コードレビューに関する話は、今のところ全部で5記事連続で配信していく予定です。応援や期待、お待ちしております。また、たまたま資料が手元に多くあるので、疑問やこういったことが知りたいという要望がありましたらご連絡頂けると記事にするかもしれません。一緒に学びましょう。
 |
Karl E.Wiegers、大久保 雅一 |
 |
ソフトウェア技術レビューハンドブック―実践的ノウハウに関するQ&A (ソフトウェア・エンジニアリング・シリーズ) ダニエル・P. フリードマン、ジェラルド・M. ワインバーグ、岡田 正志 |
