間違いだらけの備忘録

このページの内容は無保証でありこのページの内容によって直接、または間接に損害を受けられたとしても私は責任を取りません。

コードレビュー

http://d.hatena.ne.jp/camlspotter/20120814/1344919762

最高のレビュー体制を簡単にまとめておこうと思います。

利点 何故必要か 何が嬉しいのか
コスト うまく回すためには何が必要か
細かい運営方法
(中略)
結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが…
(中略)
利点

レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。
(中略)
レビューはバグを事前に見つけるだけでなく、お互いの書いたコードの批評を通してのプログラムの効率化や可読性向上、またメンバーのコード技能の伝達にもとても有効です。
(中略)
コスト

レビューのコストは高い、まずこのことを認識してください。 私の経験では本当に真面目なレビューを行うと仕事時間の30%はコンスタントにレビューに持っていかれました。 その間は外見的にはなんら新しいコードが作られないことになります。 つまりレビューなしにコードをひたすら書いている場合に比べ(狭い見方をすれば)70%しかアウトプットが無いことになります。 これはもし上層部がレビューに関するコストを甘く見ている場合、レビューは全く機能しないことを意味します。
(中略)
レビュー体制
VCS で行うレビュー
(中略)
つまり、コードの中にコメントの形でレビューを書き、それをコミットする。 そしてそこから派生する議論も全てコード上のコメントで行います。
(中略)
物理的にチームの人間が集まりレビューを行う、日本人が好きそうなこの体制(中略)時間の無駄です。 既にそのコードを知っている人には退屈だし、そのコードを担当しない人には退屈だし、そのコードを書いた人にとっては糾弾会になる恐れもある。

正論

レビューコメント例を日本語で書こうと思いましたが…難しいですね。 日本語は敬語のシステムが複雑すぎ、書く際に気を使います。 怖い上司に向けてお前のコードは読めない、という事を穏便に伝えようとする際、日本語でどう敬語を書こうかなどと考えていてはレビューの精神は半ば死んでしまう。 お互い下手な英語で生産的に罵り合う方が気が楽なのかもしれません。

素敵〜

このページにはhatena以外のサービスからのコンテンツが埋め込まれています。 hatenaによりGoogle AdSense 広告が埋め込まれています。