株式会社ヘキサドライブ | HEXADRIVE

こんにちは、タマキです。
ソフトウェアの品質を高めるために、開発にコードレビューを取り入れている話はよく耳にします
コードレビューを簡単に言えば、『あるソースコードに対して、作者とは別の人(and/or ツール)がチェックを行うこと』、になるでしょうか。
形態としても様々あり、
　・新人のソースコードに絞って、会議室などで先輩が集まって、レビュー
　・VCSで、コード内にコメントを挿入しコミット。対象者はそのコメントを見て修正しコミット
など。
また、ペアプログラミングをしているというところもあるかと思います。
以前では、このコードレビューを行うために、多くのリソースが消費されていました
例えば、以前のMicrosoftでは必ず
　1.コードを書き、単体テスト
　2.旧ソースとのdiffをチームメンバーに配り，メールベースでレビュー
　3.レビューは1行1行細かく行う
　4.全員がOKと判断したら、再度テストを行いコミット
といったことを行なっていたとのこと。
「レビューを必ず行う」というところは、とても見習うべき点ですね
ですが、『diffを配り、メールベースでレビュー』というところが、今では効率的でない感じがします。
これを効率的に行う目的で、コードレビューツールといったものがあります
現在では、有名な会社はもちろん、OSSも含めた多くの開発でコードレビューツールが導入され、品質の向上と効率化が図られています。
(有名なところでは、Google, Microsoft, Facebook, Twitter, VMware, Dropbox, Quora, …など)
ツールも、『Web上でレビューを行う』といったものが増えてきました。
ヘキサドライブでも、レビュー自体の恩恵を受けつつ、レビュー時間の削減や効率化を狙い、コードレビューツールを利用しています
このツールを用いたコードレビューの基本的な流れは、
　1.ソースコードを追加・修正・削除(複数のソースファイルもok)
　2.コードレビューツールにアップ
　　ソースコードで変更があった部分が色付けでわかりやすく表示される
　3.設定したレビュワー(複数人ok)が添削し、OK/NGなどを設定。コメント(行単位でも可)なども追記
　　もちろん、ツール上だけでなく、口頭などでも相談や提案などが行われます。
　　レビュワー以外の人がコメントなどをするのもok。
　4.OKならコミットし、クローズ
そして、ヘキサのいくつかのプロジェクトでは、Phabricator(http://phabricator.org/)を使用しています。
Phabricatorを選択した理由を、いくつか挙げると、
　・主要なVCSに対応している(Git, Subversion, Mercurial)
　・主要なクライアントに対応している(Mac, Linux, Windows)
　・導入時にPhabricator自身のソースコードをあまりいじらなくても良い
　　初めに検証したものは、ソースコード内部をいろいろ書き換えてやっと動いたという状態。。。
　　機能的にも不満ではあったが、それを抜きにしても、バージョンアップなどで追いかけるにはメンテナンスコストが高かった。。。
　・レビューをブラウザで行うことができ、差分の箇所がわかりやすい。ソース一行に対しコメントを挿入することできる
　・レビュー履歴が残る(レビューされるコードを修正しアップしなおしても、以前のものも残りつつ、アップしなおしたものも確認できる)
　・UTF-8対応されている
でしょうか。
もちろん気になる点もありましたが。。
Phabricatorだけでなく、様々なコードレビューツールが存在しますので、要件・導入コスト・習得コスト、そして好みも含め、合うものを選択すれば良いと思います。
個人的には、GitHubのPull Requestは好みです