2010-12-12

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

「プログラマが知るべき 97 のこと」 日本語版のエクストラとしてちょこっと書かせてもらいました. エッセイ集のような本で, 読切 Blog 記事一気読み, みたいなノリで読めます. ソフトウェアアーキテクトが知るべき(同上) の続編というかんじですが, アーキテクトもプログラマも大差ないので片方読んで面白かったらもう一方も楽しめると思います. (両方に書いてる人もいます...)

一編 2 ページくらいの長さに揃っているので割と読み易い一方, 私のようにぐだぐだ長々と書く傾向の人間が書くと ややあっさりしてしまう気がした. ここで続きをちょっと書きたい.

パッチのなやみ

私が書いたのは, "良いコード" と "良いパッチ" はときどき相反することがあるからどうしましょうね, という話だった. 良いコードはさておき良いパッチとはどんなものだろう. という話は本を買っていただきたくおもいますが, 端的に言えばレビュアがレビューしやすいパッチは良いパッチ, という基準で話をすることが私は多い. 更に下心を打ち明けるなら, レビュアがオッケーといいやすいパッチを良いパッチと呼びたい事もある.

私が仕事で紛れこんでいるプロジェクトはパッチ単位でのレビューを必須としている. ところがパッチの数に較べるとレビュアの絶対数が足りていないため, コードを書けばすぐレビューされるわけではない. いかにレビュアの目にとまり, レビューしてもらうか(更にオーケーを貰うか)はコードを書くときにとても気を使う. 近所の同僚がレビューできるコードなら耳元でお願いすればいいけれど, 海や会社をまたいだ誰かに見てほしい時は困る.

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

まず意図する変更が本当に大きいとき. 大きな変更は小さな変更に分割しろというけれど, 全体の意図抜きに小さい変更ひとつだけを見せられても レビュアには単なるコードあそびや金メッキに見えてしまう.

チェックを一行足せば症状は消えるけれど本当は大きく構造を直した方が良いときもある. 選択肢があるぶん単なる大変更より悩ましい. レビューのされやすい一行フィックスを選ぶか, レビュアに見過ごされる覚悟で構造の変更から始めるか. とりあえずバグを直して, それから構造を整えようか. でもバグを直したあとでも二手目をやる気になるかしら...

複数のパッチに切り分けた途端に変更の敷居があがる. これはパッチ主体の開発プロセスが抱える問題だとおもう.

隣の芝いろいろ

世のプロジェクトはそれぞれのやり方でこの問題を扱っている.

開発主体が分散していない 企業主導のプロジェクト では気軽にブランチを使うことができる. 大きな変更のためのブランチを切る. そしてブランチ上で一連の変更を行い, 切りのいいところでトランクにマージする. 変更にあわせ, 開発者はレビュアに face to face で意図を説明する. その道筋を踏まえ, レビュアはブランチ上の部分変更をレビューする.

ブランチは "複数のパッチに切り分けられた大きな変更" そのものだから, この方法は自然だし効率的もいい. 一方でレビュアと直接話をする機会を持たないプロジェクトメンバは不公平/不透明に感じるかもしれない.

Linux は 連番をつけたパッチ列をメーリングリストに投稿する. 大変更の意図は冒頭で説明する. この方法はフェアだと思うけれど, いまさらメールですか...という気にもなる. 今はもう少しモダンな方法をとっているのかもしれない.

分散バージョン管理システムを使うと, 冒頭の企業主体なブランチ方式をもっとオープンに行うことができる. たとえば Launchpad のコードレビュー では, プログラマがローカルのブランチをサーバにある自分のレポジトリにプッシュし, 本家の開発者にレビューとマージを要求する. ブランチを切るのに特権はいらないから, 誰でも同じ立場で大きな変更を始めることができる.

Launchpad がホストする SCM である Bzr のブランチは(当然)複数の変更を含む. レビュアはブランチ上の各リビジョンに対してオーケーを出すことができる. まさにこうあってほしい作りになっている. ただコードレビューツールの UI がやや前時代的で悲しい.

github の pull request もだいたい似たようなものだけれど, コードレビューの支援は LaunchPad より弱そうに見える. "レビュア" のような概念が薄い github のカジュアルな想定開発スタイルを反映しているのだとおもう.

Android で採用されている git 用のレビューツール Gerrit も 似たような仕組みを持っている. コードレビュー大好きな会社が作ったツールのため UI の出来は良い. ただし Gerrit は Launchpad のような (github のようなと言ってもいい) ユーザ単位のブランチという概念はないから, 通りすがりの人間がブランチを公開することはできない. また組込みの障害管理ツールを持っていないため, バグとブランチの対応づけはやりにくそうに見える.

どれも一長一短で決定打がないため, というわけではないけれども件のプロジェクトでツールの乗り換えが行われる様子はないので, 私は仕方なく Bugzilla で我慢している. しばらくはアドホックにのらりくらりと頑張りたい.

でも分散バージョン管理と障害追跡とまともな UI のコードレビューがくっついた, さいきょうのソフトウェアプロジェクト支援ツールがあったらきっと市場を制圧できるとはずなので誰かがんばってほしいです. あ, Wiki もつけてよね. それと...