http://blog.8thcolor.com/en/2013/10/we-dont-have-time-for-code-reviews/
We don’t have time for code reviews
OH
数年ソフトウェア開発者として働いたことがあるなら、多分二、三こんな説明を聞いたことがあるはずだ。
「コードレビューはすごくしたいんだけど、スケジュールがタイトでさ…」
「品質は大事だよ。でもエンジニアを他のエンジニアの仕事のチェックのために使うようなリソースはないんだ」
「今日の午後のコードレビューミーティングは取りやめよう。とりあえずまずsprint storyを終わらせなきゃ」もしくはこんなことを決意する。
「コードレビューをする時間は取らなくたっていい。確かにやるべきだけどできないんだからしかたがない。すっごく有用だと思うので、できないのは残念だけど」
My secret/秘訣
さて、ここで秘訣を暴露しよう。僕達はコードレビューをする時間をとってないし――なんてこった、Githubにそのタスクを入れてさえもいない。
でも僕達はコードレビューをする。コードの些細なところまで全部レビューするのだ。なぜなら、コードレビューはタスクではないからである。
Code Review/コードレビュー
秘訣を話す前にちょっと別の話をする。
何年か前、僕は大きな会社の開発チームで働いていた。最初はエンジニアとしてだったけど、そのうちチームのリーダになった。僕たちはある時期から単体テストをはじめて、すぐにそれをチーム内の「よい習慣かつ必須」のものにしていった（僕は良い習慣というのはチームのみんなに適用される必要があって、ある種の「共同体的強制力」が必要されるものだと思っている）。でも僕が上司にできたことや進行中のことを報告するとき、単体テストについては話題に触れなかった。
なぜか？
ユニットテストは切り分けられるようなタスクじゃないからだ。単体テストは機能追加やバグ修正の一部だ。同じように僕は「コミット」や「ドキュメント」もタスクじゃないと思っている。これで僕らは「単体テストを作る時間を設けるべきか会議」をいくらか回避することが出来た。
単体テストはそこではタスクじゃなかった――単に開発タスクの中の（強制的な）一部分だったのだ。
Definition of Done/完了の定義
共通する完了の定義は実際のところ極めて重要な何かに依存しているし、チーム（もちろんアジャイルの場合も同じ）を管理する。たとえばこの記事をいつ「作業中」から「完了」に移行すればよいのだろうか。移すというのはなにを意味しているのだろうか。
以前の僕のチームは、コードが書かれ、テストされる（単体テストで）ことが完了を意味していた。テストが書かれていなければ、終わったことにはならない。
とても単純だ。
Today
8th colorでも単体テストのタスクはないし、チケットリストの中にたとえば「コードレビュー」というチケットを見つける事はできないだろう。なぜなら、もう一回言うけど、コードレビューはタスクとは切り離せない。コードレビューはUser Storyの一部だからだ。
もっとも、僕は嘘をついた。Githubの中にコードレビューのチケットはある。Pull Requestとして上がっているからだ。でもこれについて考えるときPullRequestは単なる状態だということが分かるだろう。状態っていうのはつまりチケットが「レビュー可能な状態になった」ってことだ。このシンプルなステップを表現するのはコードレビューのワークフローに沿っていて極めて実際的だ。
（略）This entry was posted in technical and tagged code review on October 23, 2013 by Martin.
