コードレビュー

どうもコードレビューなんてほとんどやったことないwyukawaです。こんにちは。

Review Boardならコードレビューを効率良くできる！ (1/3)：ユカイ、ツーカイ、カイハツ環境！（19） - ＠IT

は面白そう。プレコミットレビュー方式なんだね。レビューOKまでコミットしちゃいけないという運用はトランクをきれいに保てる。

9 月号, "わかるバージョン管理システム" は, Mercurial 開発者の Bryan O'Sullivan による DSCM 入門. ツールの使い方ではなく DSCM の有難味に 重点を置いているのがそこらへんの入門記事と違うところ. cherrypick, bisect, rebase といった DSCM 固有のアイデアを駆け足で紹介(cherrypick では Darcs の特徴的な依存モデルにも言及)しつつ, DSCM がもつコードレビューとの親和性の高さにきちんと言及するあたり, さすがにわかってるなあ. (なお Bryan O'Sullivan の熱い SCM 語りは Mercurial: The Definitive Guide の一章でも楽しむことができます.)

Communications of ACM

分散バージョン管理使えばトランクに入る前にコミットして管理しておくこともできる。ま、SVNでもブランチ切ればできるね。

ただレビューの粒度は難しい問題ですね。

プログラマが知るべき97のこと

の8の森田さんの「育ちのよいコード」にもあるようにあるパッチが１ファイルの同じ場所でおさまるならそれは高凝集、粗結合なソフトといっていいかも知れません。これならレビューもしやすい。

俗説によれば, パッチのサイズとレビューされやすさは反比例する. 小さいパッチほどレビューされやすい. けれどいつもパッチを小さくできるとは限らない.

プログラマが知るべき 97 のこと

まあ、そうでしょうね。

http://www.ustream.tv/recorded/12026561

でコードレビューの話がでていて以下の表がでてました。縦が変更の粒度です。下にいくほど大きい。リリース単位の変更だと関係者も多いし、それをコミット後にレビューしようとしてもそれは次がんばりましょう的な反省会になるだけなので残念ということらしい。

	コミット前（トランクマージ前）	コミット後（トランクマージ後）
パッチ
機能
リリース		残念なパターン

パッチ単位ならレビューしやすいし、上述のReview Boardを使えばdiffを見ながらできるのでやりやすい。しかし逆にいえばdiffとして表示されないものはレビューされないし、大局的には見れないとのこと。なるへそ。全然関係無いけど森田さんのトーク面白いですw

WebKitはレビューしないとコミットされないというかなり厳密なプロセスのようです。
ま、
Changeset 70000 – WebKit
をレビューしてるかどうかは疑問ですがw

そんなWebKitですが、本家のコードをチェリーピックしてポートしたりしているのでポート先がどのバージョンのWebKitベースなのか判定できないという面白い（と言っていいのか？）状況のようです。
リリース担当者大変でしょ。これ。しょうがないんだろうけど。

WebKit はアーキテクチャで可搬性を担保するかわりに, とりあえず Mac で動かして他のポートは各人が頑張って追従するという, 良くいえばソーシャルなアプローチで可搬性を実現している. おかげで野心的な可搬アーキテクチャにありがちな オーバーヘッドなしに新しい機能を取り込んでいける. かわりに皺寄せもリリースの断片化といったソーシャルな部分にあらわれているのはやや悲しい.

一方で可搬性という工学上の問題を高度な設計ではなくバザール的な人海戦術で, しかもいくつもの企業から集まった会社員プログラマの人月で解決していく WebKit の様子は, オープンソースプロジェクトのあり方として面白いとおもう.

WebKit はリリースしない

というWebKitの状況を見つつHudson(Jenkins)はというと、以下の動画で述べられています。

http://www.ustream.tv/recorded/12020248

簡単にいうと、誰でもコミッタになれて、レビュープロセスなしです。スピード感重視。リリースも毎週です。分割統治を強く意識しているようです。プラグイン文化も花盛りです。

プロジェクトの特徴が出ていて面白いですね。