読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

コードレビューについて思うこと

Project Management

以下のブログ記事を読んで感じたこと。「コードを書いたことがない人にコードレビューをしてもらうこと」について。爪に火を灯すが如くに効率化を求められる世の中なので、ムダな事はどんどん止めるようにしないとやっていられないだろう。

意味のあるコードレビューなのかどうか

上記の記事でリンクされている過去記事でも似たようなことが書かれているけれども、レビューが目的を達成する手段として有効であれば実施すべきだし、有効でないのであれば削ってしまえば良いと思う。

  • 基本的にはバグ・欠陥の早期摘出が目的だと思うので、この目的に対して有効な「コードレビュー」が出来るのであれば良い。
  • 「コードを書いたことがない人」は「コードレビューすべきではない」とまでは思わない。(そのアーキテクチャの良し悪しは別として)設計をストレートにプログラムに落としこむようなソフトウェア開発の方法論を適用しているのであれば、インプットの設計書とコードを突き合わせて実装漏れを確認するようなチェックが有効であることもある。
  • 他にも設計に落し込みにくい「ビジネスルールの暗黙知」や「地雷」を回避する目的で有識者にレビューしてもらうというのも、やることはあって良いと思う。ただコードレビューの段階でこれをやるのはなかなか難しい。保守拡張開発の場合のみに限られるかもしれない。
  • 例えばコードの洗練などを狙っているのに、「コードを書いたことがない人」がレビューするのは無意味だと思う。
  • 漠然となるのはもってのほか。

ソフトウェア開発におけるすべてのプロセスと同様、問題は「コードレビューが良いか悪いか?」ということではありません。問題はそうではなく、「コードレビューが役に立つのはいつなのか、役に立つときはどれが最善のプラクティスなのか?」ということです。
Making Software ―エビデンスが変えるソフトウェア開発18 章 近年のコードレビュー、より

不適切なコードレビューの風習は、トラブルが発生したときの再発防止策の検討などで仕込まれることが多いと思う。「コードレビューを強化してトラブルを防止します」といった再発防止策を採用することが、打ち手としてはよろしくない。このあたりも注意が必要だと思う。

古い習慣を捨てるための最初の一歩は、自分のやり方が時代遅れだと気づくことだ。
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 7 時が来たら習慣を捨てる、より