2011-02-19
はじめての Chromium Land
はじめてまじめに ...といってもたぶん 500 行くらい... WebKit ではなく Chromium 側のコードを書いている. まだレビューをとおってないため現在形. でかすぎてビルドの遅い Chromium より Mac WebKit をいじる方が快適という同僚もいたけれど, コード自体は Chromium の方がだいぶモダンだよなあ. 普通に unit test が書けるありがたさといったらない.
Developer testing
まず gtest が良くできていて感心する. static initializer を使ってケースの登録を分散化したり, コマンドラインフラグでテストケースを一覧選別できたり, プロセスを分離してクラッシュに強くしたり, クラッシュしたテストケースの backtrace をだしたり. でかい C++ のコードベース相手にテストをスケールするための工夫が凝らしてある. オープンソースになっていてよかった... (プロセス分離は gtest ではなく chromium のテストベッドががんばっているようす.)
テストが書けるということはオブジェクト同士も最低限の isolation ができているということなので, 全てが相互依存な WebKit と違い依存関係もそこそこよく考えられている. インターフェイスでの間接化が徹底されてるわけではないけれど, WEwLC 初級編くらいの小手先で切り離せる.
テストベッドにはクラス単位のテストを書く unit test とアプリケーションのインフラに依存できる browser test など複数の種類があり, たとえばスレッドをまたぐメッセージを投げてイベントループで返事を受けとるようなテストも browser test なら書ける. 自分のクラスに閉じたロジックには unit test を書き, OS の API べったりで isolation の不十分なコードには browser test を書く. ブラウザオブジェクトやメッセージループといったインフラ寄りのインスタンスを テストケース単位で生成破棄できる最低限のライブラリらしさがあるからこそ browser test は実現できる. フレームワークの中にアプリケーションの寿命が隠されてしまう古典的な悲劇はない. GUI の動きを試すようなテストはもうちょっと面倒そうだけれど, 更に別の仕組みでなんとかテストできるらしい.
browser と renderer の IPC に目をやると, 本体のコードを書くのは面倒. ただそのあとのテストは書きやすい. プロセス分離のおかげでモジュールが強制的に分離されており, 通信 channel をフックしメッセージを横取りすれば簡単にフェイクできる. RPC で通信するネットワークプログラムのテストを書く感覚に近い.
Carnitas
これまでの Chromium は IPC 周辺のデザインに少し手抜きがあって, メッセージを分配するクラスが肥大化しコードが悲惨になりかけていた. それもいま Carnitas と呼ばれる大リファクタリングの一環で整理されつつある. おかげで IPC の処理を単一のクラスに押し込むのではなく役割に応じてクラスを抽出できるようになった...まあ普通の話なんだけれども... Rails でいうと一個しか Controller がなかったアプリケーションの URL を整理して複数 Controller に処理を分配したかんじ.
市場にそれなりの競争があるウェブブラウザ開発で 機能追加の圧力に負けず...というか順当にいくと圧力に負けることを見越し, トップダウンでリファクタリングを敢行するのはえらい. 私にとってのリファクタリングは上司や客の目を盗んでこそこそやることだったから, エースプログラマ以下精鋭数名が率先して大規模なリファクタリングを計画実行する様子には内心驚いた. コードの腐敗に負け新バージョンをフルスクラッチしてトップダウンに自爆する時代は遂におわった! 21.1 世紀万歳!! C++ だけど!
実際のところ新入りや下っ端が骨組を直せる規模のコードベースではないから, 全貌を見通せる人間が手を下さないとコードを良くするのは難しい. 私のパッチも最初は件の巨大 Controller クラスにちょこちょこと関数を追加する典型的なまずい仕事だったため, レビューで Carnitas に従ったデザインにすべきと指摘された. そこではじめて自分のコードと件のリファクタリングの関係を知り, 資料を読んで出直したのだった. メールはちゃんと読もう...
異国情緒
とはいえ私はふだんぜんぜん違うコードベースで仕事をしているから, たまにしきたりの違うコードを書くと戸惑う. いちばん困るのはコメント. WebKit はぜんぜんコメントを書かないし, 最近おきたメーリングリストの議論 でも多くの開発者がそれを支持した. 会社員になって以来ずっとコメントレス生活を送ってきた私も断然これを支持している.
ところが Chromium のコードはスポンサーの意向できっちりコメントを, 特にクラス単位での説明を書かなければならず, いまいち慣れない. レビューで public なクラスにはコメントをつけろと指摘され再提出したパッチに またしてもコメントのないクラスを定義してしまいかなりレビュアにあきれられた. ごめんなさい... 他にもいろいろとあきれられがちなコードを書いてしまったのだけれどはずかしいので割愛.
ただ社内コード歴のながい同僚にコメントめんどくさいよねーと話してもまず共感は得られない. 私もコメントなんて要らないといいつつ他人の書いた Chromium 内のコメントは熟読のうえ理解の足しにしているから, 自分はただ英語で何か書くのを億劫がっているだけなのかも知れない. 改宗に心がゆれ, たまに混じっているコメントのないクラスを見て我を取り戻したりしている.
もう一つ肌があわないのが改行幅. この大画面なご時世に 80 字で改行はナシだろ... これを決めたやつは絶対ターミナル上の vi で仕事をしてるに違いないと内心憤慨しているけれども 宗教論争をしてもいいことはないしコミット前チェックツールには逆らえない. まあそのうち慣れるとは思う.
こうして雇用主テクノロジの雰囲気に触れるコードを書き心あらわれた気分になると, 自分はふだんタダメシの恩恵にあづかるばかりで何か大切な学びの機会を逃しているのではと ちょっと不安になったりもした. WebKit のべらんめえなところも結構好きなんだけどね.
参考: