Comparators―比べてみればわかること

第1回 Hackability vs. Hackiness

この記事を読むのに必要な時間:およそ 4 分

WebKitに見るHackabilityの指標

では,コードの中のHackabilityは何が左右するのでしょうか。

オープンソースのHTMLレンダリングエンジンWebKitは,プロジェクトのゴールの一つにHackabilityを挙げています。プロジェクトに大きな判断が求められる議論では,このゴールがたびたび引き合いに出されます。

あるときWebKitにユニットテスト用のフレームワークを追加しようと提案があり,やはりHackabilityが俎上(そじょう)に載りました。サードパーティのテスティングフレームワークを採用するならHackableなものを選ぶべきだというわけです。議論されたHackabilityの指標は主に次の2つでした。

  • ① コードを書き換えたら,差分は本家に取り込んでもらえるのか?
  • ② 都合に合わせて変更できるわかりやすいコードなのか?

これはオープンソースにおけるHackabilityの特徴をよくとらえています。つまりオープンソースのHackabilityには①のようなプロジェクトの文化的,政治的側面と,②のようなコードにまつわる側面があるのです。変更しやすい,そして変更が取り込まれやすいオープンソースのソフトウェアほどHackableである。腑に落ちる説明ではないでしょうか。

ソフトウェアの保守性とHackiness

変更を加えやすいコードほどHackableなのは,何もオープンソースに限りません。コードの中に手を加えてハックをするなら,ライセンスにかかわらず書き換えやすいに越したことはないからです。読みやすく変更しやすい,要するに保守性の高いコードほどHackabilityは高くなります。

……本当でしょうか?

Hackabilityを気にするとき,私たちがやりたいのは開発の続きではありません。ハックです。私たちはそのコードにHackinessの高い変更を加えたいのです。私たちはふとしたアイデアを試したいのです。あるいはちょっとした不足を埋めたいのです。あるいはただ,それがどんな風に動くのか,少しだけ壊して確かめたいだけなのです。寝る前に,昼休みに,週末に,手早く,気楽にいじりたいのです。綿密に組み立てられ,冗長性を排し,すべての知識をコードに埋め込もうと意気込んで書かれた「保守性に優れたソースコード」は,はたしてこうしたハックを許すでしょうか。

しなやかさとおおらかさ

考えぬかれた洗練は,それ自体が欠点にもなります。洗練されたコードに手を加えようと思ったら,プログラマは元の開発者と同じくらい考え抜き,洗練された設計でコードを書かなければいけないからです。Eric Evansはこの洗練を「しなやかな設計」と呼びました注1⁠。

しなやかさはプロジェクトを通じた学びの証です。新参開発者がもとの書き手と同じ険しい学びのプロセスを経る必要はありません。しかし,少なくともその成果を学ぶ必要はあります。精巧に組み立てられた抽象には型システムや自己検証といった防御が施され,安易なやっつけ仕事を許さないからです。私たちは丁寧にコードを読み,編みあげられた意図を解きほどく必要があります。

しなやかなコードを読むのは楽しいものですが,ハックの下準備としては大げさ過ぎます。ハックをする私たちは開発チームの新メンバーというわけではありません。ふらりと遊びにきた通りすがりです。宴会のない土曜の夜,コーヒーを淹れてエディタを立ち上げ,チェックアウトしておいたコードからgrepとデバッガを頼りに目当てとなる場所の当たりをつけ,適当にブランチを作りがちゃがちゃと書き換える。ハックとはそんな風であってほしいと思いませんか。

だとしたら,Hackabilityの高いコードには何が必要なのでしょう。私はこんな風に考えています。

しなやかさを支えるのが抽象を貫く「規律」だとしたら,Hackabilityを支えるのはHackinessを受け入れる「おおらかさ」である。

ちょっとくらいヘンなヤツ(ハック)が紛れ込んでも大目に見ることのできる「おおらかな」コードほど,私たちはHackableだと感じるでしょう。たぶんそうしたコードにはリフレクションや型システム,知られざるシステムコールなどを駆使する粋なマジックなんてありません。テストはあるけれど適当で,ときどき驚くようなリグレッションが見つかるでしょう。そして誰かの書いたHackyなコードがあちこちに顔を出して私たちを驚かすでしょう。

Hackableなコードはどこかおおざっぱで,ありていに言えば大したことのないコードに見えます。けれどそもそも,そのコードには私たちにハックしようと思わせる何かがあったはずです。つまりコード以前に私たちの気を引くところがあるソフトウェアなのです。そして中を覗きこんだ私たちを迎え入れてくれたのがHackinessだったのです。

注1)
Eric Evans 著/今関剛 監修/和智右桂,牧野祐子 訳『エリック・エヴァンスのドメイン駆動設計』翔泳社,2011年,第10章

Hackinessの限界

通りがかりにやさしいHackinessを応援したい一方で,そのおおらかさが持つ限界も認めないわけにはいきません。

Hackinessはコードを引き寄せます。ハックによって書かれたコードが取り込まれたソースツリーはどんどん成長します。凝った抽象のない単純なコードに雑多な追加が積み重なり,熟読なしに入り込めた敷居の低いコードは,いつか人波のごったがえす,誰の手にも負えない割れ窓だらけのスラムに姿を変えます。あちこちで諍(いさか)いが目立ち始めます。テストが真っ赤のままリリースに踏み切って阿鼻叫喚(あびきょうかん)が巻き起こり,現場にかけつけたあなたは言葉を失います。いつの間にこんなことになってしまったんだ……。

歴史あるソフトウェアにはよくある光景です。ハックは時が経つと負債に姿を変えます。どこかでしなやかさを取り戻さない限り,そのソフトウェアは複雑さに足を取られ進めなくなるのです。そんなとき,何か打つ手はあるのでしょうか。

HackinessからHackabilityへ

プラットフォームのHackabilityを思い出してください。それは,ソフトウェアの「上で」行われる遊びでした。コードの「中に」負債として積み重なったハックをよく見ると,実は「上に」持ちあげられるものが多く混じっていることに気がつきます。しかも,それら「上向き」のハックが現れる場所はコードの一部に偏っていませんか。呪われた1,000行に目を凝らせば,10回分の100行ハックが見えてくるのではないでしょうか。

ハックのアイデア,ソフトウェアに求める新しい機能は,案外似通ったものになりがちです。したがって積み重なったハックはソフトウェアに機能追加の柔軟性を求めるシグナルだと解釈できます。⁠ここはもっと汎用的に作ってくれ⁠⁠,一連のハックはそう知らせます。コードにしなやかさを迎え入れる日がきました。リファクタリングをしてAPIを作りましょう。そして呪われた1,000行を,ごっそりAPIの「上に」押し出しましょう。私たちのソフトウェアをハックの塊からハックのプラットフォームへと成長させるのです。

あちこちに溢れていたハックがAPIの上に歩み去ると,コードからは秩序と入れ替わりにHackinessが失われます。このときある種の喪失感がよぎります。遊び心が,冒険心が失われた。そんな気持ちです。

でも悲しむことはありません。巣立っていったHackinessたちは,私たちの上で新たな楽しみを見いだすでしょう。そこではまた新しい遊びが,ハックが産まれることでしょう。規律に追い立てられしなやかなまま育った品の良いソフトウェアがこうしたハックをはぐくむことは多くありません。一方Hackinessを内包したおおらかなソフトウェアはハックを育て,自身も段々とHackabilityを身につけていきます。バグだ,パッチだ,フォークだと騒がしい末裔(まつえい)たちに囲まれ苦笑いする。それがきっと,私たちの望んだ成熟の姿なのです。

著者プロフィール

森田創(もりたはじめ)

平日はWebブラウザの開発,休日はWebブラウザの利用に従事。最近の趣味は/etc/hostsファイルに中毒性の高いWebサイトをリストし,127.0.0.1にリダイレクトすること。現在7サイト。スマートフォンの勉強をしなければと思いつつ/etc/hostsにアクセスできない端末を持つのが不安で躊躇している。

http://steps.dodgson.org/