エンジニアリング哲学：Linus Torvalds、消えてなくなる特殊ケース

要点

• 良い趣味とは、特殊ケースが消えてなくなることです。 データ構造を作り変える――ポインタではなくポインタへのポインタにする――と、エッジケースを処理する if には、もはや居場所がなくなります。
• 「コードを見せろ」はスローガンではなく、認識論です。 設計とは仮説にすぎず、議論に決着をつけられるのは実際に動くコードだけなのです。
• git は、分散をそのデータ構造の必然的な帰結にしました。 内容アドレス方式のオブジェクトは、すべてのリポジトリを対等にします。だからこそ「唯一の正本」など最初から存在せず、守るべきものもないのです。
• 規模における信頼は、前提にするのではなく、構造化しなければなりません。 Torvalds はこの問題を二度解きました。誰が責任を負うかを示すメンテナのツリーと、何が起きたかを示す改竄検知可能な履歴です。

原則

「問題を別の角度から見て、特殊ケースが消えて通常ケースになるように書き直せることがある、ということを理解してほしい。それが良いコードだ」――Linus Torvalds、TED、2016年¹

Torvalds は TED のステージで、2つの C 関数を並べて掲げていました。どちらも単方向リンクリストからエントリを削除するものです。1つ目は prev ポインタでリストをたどり、削除対象が先頭かどうかを判定し、分岐させていました。先頭は特殊ケース、それ以外はすべて一般ケースとして扱うのです。10行、if が1つ。2つ目の関数はポインタへのポインタ――**indirect――でリストをたどり、先頭をまったく特殊な位置として扱いませんでした。先頭とは、たまたまポインタへのポインタが最初に指していたもの、それだけです。4行、if なし。¹

行数が少ないことが眼目だったわけではありません。1つ目の版に条件分岐が存在したのは、プログラマがリストの先頭をリストの残りとは別物としてモデル化したからにすぎません。より良いデータ構造を選ぶ――ポインタではなくポインタへのポインタにする――と、その違いは蒸発します。エッジケースは問題に本来備わっていたものではなく、問題をどう表現したかが生んだ産物だったのです。Torvalds の言う趣味とは、まさにこの一手であり、それは趣味を技術的なシステムにするのと同じ信念です。趣味とは美的な好みではありません。優美な版が勝つのは、見た目が美しいからではなく、間違いうる箇所がより少なく、より正しいからなのです。

その本能――特殊ケースをなくし、エッジケースに隠れる場所を与えない――は、Torvalds が築いたすべてに通底しています。それはまた、彼のもう1つの有名な台詞が、マニフェストというより指示書のように読める理由でもあります。「能書きは安い。コードを見せろ」²

上で試してみてください。中間のノードを削除し、次に各モードで先頭を削除してみましょう。「当たり前のやり方」では先頭が if (!prev) の分岐に引っかかりますが、「良い趣味」では先頭もただのリンクの1つにすぎず、同じ1行がそれを処理します。

背景

Linus Benedict Torvalds は1969年、フィンランドのヘルシンキで、スウェーデン語を話す家庭に生まれました。ヘルシンキ大学のコンピュータサイエンスの学生だった彼は、Minix を使っていました。オランダ人教授 Andrew Tanenbaum が教材として書いた、小さな Unix ライクなオペレーティングシステムです。Minix は学びには役立ちましたが、意図的に制限されていました――Tanenbaum は、学生が全体を読み通せるよう、あえてシンプルに保っていたのです。Torvalds は、許された以上のものを求めました。

1991年8月25日、彼は comp.os.minix という Usenet ニュースグループに投稿しました。「386(486) の AT クローン向けに（無料の）オペレーティングシステムを作っている（ただの趣味で、gnu のように大きくてプロフェッショナルなものにはならない）」³ この括弧の中の控えめな但し書きは、ソフトウェアの歴史でもっとも引用される見込み違いです。

その趣味は、あらゆる展開規模の指標で見て、地球上でもっとも広く動いているカーネルになりました――ウェブサーバの大半、すべての Android スマートフォン、そしてクラウドとスーパーコンピューティングのインフラの圧倒的なシェアを支えています。

アーキテクチャは当初から論争の的でした。1992年初頭、Tanenbaum は「LINUX は時代遅れだ」と題したスレッドを立て、モノリシックカーネルは「1970年代への巨大な後退」だと論じ、マイクロカーネル――オペレーティングシステムを、互いに隔離されたメッセージ受け渡し型のサービスへと分解する方式――こそが未来だと主張しました。⁴ Torvalds は、マイクロカーネルが「理論的にも美的にも」優れていることは認めつつ、モノリシックなものを作り続けました。それが動き、速く、出荷できたからです。この論争は、ある気質の創設文書として記憶されています。理論は、動くシステムの前に敗れるのです。

仕事

Linux カーネル（1991年〜）：スケールしたモノリス

Linux はモノリシックカーネルです。スケジューラ、メモリマネージャ、ファイルシステム、デバイスドライバが、すべて単一の特権アドレス空間で動きます。Tanenbaum の批判は理論上は間違っていませんでした――モノリシックなドライバの障害は、マイクロカーネルなら隔離できるようなかたちで、システム全体を巻き込んで落としかねません。Torvalds の答えは経験的なものでした。モノリスのほうが速く、書くのが簡単で、しかも何千人もの貢献者が、まずメッセージ受け渡しのプロトコルを学ばずとも改変できました。学問的な論争に敗れたアーキテクチャが展開戦争に勝ったのは、それが貢献のコストを下げたからなのです。

今日のカーネルは、これまでに作られた共同エンジニアリングの成果物として最大級のものの1つです――数千万行、リリースごとに数千人の貢献者。その規模のどれ1つとして、あらかじめ設計されたものではありません。それは、マージされたパッチ1つひとつによって積み上がっていったのです。Torvalds 自身が発明せざるを得なかった開発モデルのもとで。

メンテナモデル：ツリーとしての信頼

Torvalds は、Linux に入るコードのほとんどを読んでいません。読めないのです――その量は、一人の人間にとうてい手に負えません。代わりに、カーネルは信頼の階層によって統治されています。サブシステムのメンテナが各自の領域を所有します。彼らはパッチをレビューし、自分のツリーに取り込み、上位の副官たちへ、そして最終的には Torvalds へとプルリクエストを送り上げ、Torvalds は自分が信頼するツリーをマージします。彼は根に座る慈悲深い独裁者ですが、その本当の仕事は、彼らが生み出す全行を監査することではなく、誰を信頼するかを見極めることなのです。

メンテナのツリーは社会的なアーキテクチャであり、それは現代のあらゆるソフトウェアサプライチェーンが直面するのと同じ問題に向き合っています。すべてを自分で検証することはできない、だから信頼は前提にするのではなく構造化しなければならない、という問題です。だからこそリポジトリが自らの信頼性に投票してはならないのであり、オープンソースはセキュリティの境界ではないのです――多くの目が役立つのは、誰かが見ることに責任を負っているときだけです。あの遠慮のないレビューで知られるメーリングリストこそが、信頼のツリーを可読なものにする仕組みです。決定とその理由づけは公開され、保管され、誰のものかが帰属できるのです。

git（2005年）：データ構造としての分散された信頼

長年、カーネルは BitKeeper を使って開発されていました。プロプライエタリな分散バージョン管理システムで、その作り手がプロジェクトに無償使用を認めていたのです。2005年、ライセンス紛争でその取り決めが崩壊し、Torvalds は突如として、カーネルのワークフローを扱えるツールを失いました。⁵ そこで彼は自分で書きました。git への最初のコミットは2005年4月7日。10日ほどのうちには、それ自身をホストし、カーネルを管理するまでになっていました。⁶

git をリンクリストの例と同じ原則の表現たらしめているのは、その中核のデータ構造です。git は差分を保存して状態を復元するのではありません。あらゆるファイルのあらゆるバージョン、あらゆるディレクトリツリー、あらゆるコミットが、それ自身の内容の SHA-1 ハッシュで名付けられたオブジェクトとして保存されます――内容アドレス方式のストアです。Torvalds は、ハッシュ化が「セキュリティのためだったことは一度もない。破損を見つけるためだった」と明言しています。⁶ 同一性がすなわち内容なのです。同じバイト列を持つ2つのファイルは自動的に同じオブジェクトになり、1ビットでも反転すれば違う名前が生まれ、検知できます。そして「どのリポジトリも同じで対等」だからこそ、特権的な中央サーバは存在しません――「唯一の正本」という特殊ケースは、「リストの先頭」という特殊ケースが消えたのとまったく同じように消えるのです。⁶ 分散は git に後付けされた機能ではありません。正しいデータ構造を選んだことの帰結なのです。

その最後の性質――内容アドレス方式のコミットが連なる、改竄検知可能な鎖――こそが、コミットグラフがコードを超えた意味を担いうる理由であり、私がセッションこそがコミットメッセージであると考える理由です。履歴は成果物であって、その副産物ではないのです。

方法

Torvalds の方法は、証拠によって徹底された実用主義です。「能書きは安い。コードを見せろ」は、自分のパッチが何をするかを説明していた相手への、カーネルのメーリングリスト上での文字どおりの返信でした。² 設計は仮説であり、パッチは実験です。コードが存在し、動くまでは、議論は決着しません。

その下には、エンジニアリングの判断が実際にどこに宿るかについての、彼のもっとも精密な言明があります。「悪いプログラマはコードを心配する。良いプログラマはデータ構造とその関係を心配する」⁷ リンクリストの例は、この一文を具体にしたものです。データ構造が正しければ、それを操作するコードは短く、分岐もわずかになります。複雑さはすでに構造が吸収しているからです。データ構造が間違っていれば、特殊ケースのかたちで永遠に代償を払うことになります――悪いモデルを取り繕うためだけに存在する if 文として。コードを心配するのは、症状を治療することです。データ構造を心配するのが、治療そのものなのです。

統治の方法は、技術の方法と一致しています。慈悲深い独裁者と副官たちのモデルが存在するのは、エゴを集中させるためというより、マージの決定を単一の趣味に対して説明可能なものに保ちつつ、レビューの労力を各サブシステムにもっとも近い人々へと分散させるためです。そして彼のコードレビューの遠慮のなさ――それは、彼自身が後に認めているとおり、ときに無用なまでの辛辣さに踏み込んだこともありました――も、同じ根から来ています。コードは、それが正しいかどうかで判断されるのであって、誰が書いたかや、どれほどの労力を表しているかで判断されるのではありません。届け方はそうでなかったときでも、基準はあくまで非人格的なのです。

影響の連鎖

彼を形づくった人々

Andrew Tanenbaum と Minix。 Minix は、Torvalds が学んだオペレーティングシステムであり、彼が乗り越えようとしていたものでした。Tanenbaum は彼に、読める Unix ライクなシステムを研究材料として与え、そして「LINUX は時代遅れだ」論争を通じて、Torvalds が何を大切にしていたかをくっきりと浮かび上がらせるほど鋭い、好敵手を与えました。満足させるアーキテクチャよりも、出荷されるシステムを、という価値観です。（形成的な影響）⁴

Unix と GNU のツール群。 Linux は設計の系譜において Unix です――プロセス、ファイル、パイプ、すべてはファイルという抽象。そしてそれが役に立ったのは、GNU プロジェクトのコンパイラ、シェル、ユーティリティが、その上で動くものとしてすでに存在していたからにほかなりません。Torvalds は、カーネルがまともに何かをできるようになる前に、bash と gcc を移植していました。³ 彼は欠けていた1つのピース――カーネル――を作り、残りは既存のピースに任せたのです。必要なものを作り、うまく動くものは再利用する。（直接的な影響）

彼が形づくった人々

オープンソースの世界全体。 Linux は、世界中に分散したボランティアと企業のハイブリッドが、最大規模においてプロプライエタリなチームを上回るエンジニアリングをやってのけられることを証明しました。そしてメンテナモデルは、大規模なオープンプロジェクトの運営の型になりました。

その後のあらゆる分散バージョン管理システム。 git はただ勝っただけではありません――基盤そのものになったのです。GitHub、GitLab、そして現代のプルリクエストのワークフローは、すべて、Torvalds があの10日間で選んだ内容アドレス方式の分散モデルの上に築かれています。データ構造は、それを生んだ緊急事態よりも長く生き延びたのです。

貫くもの

John Carmack と Torvalds は、正反対の専門分野から同じ場所にたどり着きます。Carmack は、アルゴリズムとハードウェアが無駄なくかみ合うまで問題を絞り込みます。Torvalds は、データ構造が特殊ケースを消し去るまで問題を作り変えます。二人とも、性能と優美さを、別々の側面から見た同じ性質として扱い、二人とも、明らかに動くものを理論に覆させることを拒みます。良い趣味は、このシリーズを通じて、けっして装飾を意味しません。それは、感じ取れる正しさを意味するのです。（シリーズの橋渡し）

ここから私が受け取るもの

リンクリストの教訓は、私がもっとも頻繁に手を伸ばすものです。コードが「最初の1つ」や「空のケース」や「管理者ユーザ」を処理するために if を生やすとき、その分岐はたいてい、データモデルがわずかに間違っているという告白です。直し方が、より良い if であることはめったにありません。より良い表現にすることであり、そのあとには、その分岐が守ろうとしていたケースがもはや起こりえなくなるので、分岐そのものが不要になります。それこそが、考えうるもっとも安あがりな防御です。存在しえないエッジケースには、処理するコードなど要らないのです。

2つ目の教訓は、規模における信頼についてのもので、いま私が築いている世界――1行ずつ自分で書いたわけではない仕事を編成する、エージェントのシステム――でこそ、もっとも重みを持ちます。Torvalds は同じ問題を二度解きました。社会的には、誰が責任を負うかを構造化するメンテナのツリーで。技術的には、何が起きたかを改竄検知可能にする git の内容アドレス方式の履歴で。Torvalds がカーネルのパッチをすべて読めないのと同じように、あなたもエージェントが生み出すものをすべて読むことはできません。だからあなたは、彼がしたことをするのです――信頼を構造的なものにし、履歴を検証可能にする――。それはまさに、私が趣味をインフラとして、サプライチェーンを攻撃面として扱う理由です。趣味から1つのカーネルを築き上げた規律は、コードベースを劣化させるのではなく加速させる規律と同じものです。構造を正しくすれば、特殊ケースは増殖をやめるのです。

FAQ

Linus Torvalds の言う「良い趣味」のコードとは何ですか？

2016年の TED インタビューで、Torvalds はリンクリストから項目を削除する2つの実装を使って、良い趣味を定義しました。彼が趣味の悪いものと呼んだ版は、リストの先頭の削除を特殊ケースとして扱うために if 文を使っていました。彼が良いコードと呼んだ版は、ポインタへのポインタを使い、先頭をもはやまったく特殊ケースではなくしていました。彼の要約はこうです。「問題を別の角度から見て、特殊ケースが消えて通常ケースになるように書き直せることがある。それが良いコードだ」¹

Linus Torvalds は何を作りましたか？

Torvalds は Linux カーネルを作りました。1991年8月25日に comp.os.minix ニュースグループで初めて告知したもので、いまや世界でもっとも広く展開されているオペレーティングシステムのカーネルです。2005年には、Linux プロジェクトがプロプライエタリな BitKeeper ツールへのアクセスを失ったあと、分散バージョン管理システムである git も作りました。彼は今も Linux カーネルの主任メンテナを務めています。³⁵

Linus Torvalds はなぜ git を作り、どれくらいの期間がかかったのですか？

Linux プロジェクトは、2005年のライセンス紛争でプロジェクトの無償アクセスが終わるまで、プロプライエタリな分散バージョン管理システムである BitKeeper を使っていました。Torvalds はその代替として git を書きました。最初のコミットは2005年4月7日で、10日ほどのうちにはこのツールがカーネルを管理していました――もっとも彼は、それに先立つ数か月を設計の検討に費やしていたと述べています。⁵⁶

「能書きは安い。コードを見せろ」とはどういう意味ですか？

Torvalds は2000年8月25日、あるコードが何をするかについての議論への直接の返信として、この台詞を Linux カーネルのメーリングリストに投稿しました。² それは彼の実用主義を捉えています。やり方の説明は仮説にすぎず、議論は、実行してテストできる動くコードが存在するまで決着しないのです。（注：関連する「十分な数の目玉があれば、すべてのバグは浅い」は、Eric Raymond が定式化したリーナスの法則であって、Torvalds 自身の発言ではありません。⁸）

出典