好きなもの
好きなものと、その理由の記録。
意味のある名前
名前が意味をそのまま表すのが好きです。良い名前は、読むだけでそれが何かを教えてくれる。
IUPAC 系統名（化学）
「2-メチルプロパン」。この名前は分子の構造をそのまま綴っています。主鎖はプロパン、炭素三個が一列に並び、2 位の炭素にメチル基が一つ付く。図鑑を開かなくても、名前から構造式が描けます。俗名の「イソブタン」は呼びやすいけれど、名前に構造はありません。何と呼ぶかは分かっても、どんな形かは分からない。
この発想には原点があります。1787 年の『Méthode de nomenclature chimique』が起こした命名改革は、化学の名前を、個別に覚える記号から規則で導けるものへと変えました。
逆から考える
逆から考えるのが好きです。正面から通れない道も、裏返すと見えてくることがある。
逆に考えよ、常に逆に
マンガーが 1986 年にハーバード校の卒業式で行ったスピーチは、題からして逆です。『どうすればみじめな人生を送れるか』。幸福の話を、裏返して語る。その中で彼は数学者ヤコビの言葉を引いています。『逆に考えよ、常に逆に』。
このスピーチは『穷查理宝典』に収められています。
一つのことを、うまく
一つのことだけをする小さな道具が好きです。プログラムはそれぞれの役割を、うまくやり遂げる。あとは組み合わせに任せます。
各プログラムは一つのことを、うまく
1978 年、『Bell System Technical Journal』の Unix 特集号は、一篇の序文とともに刊行されました。そこにはこの流儀が四つの箴言にまとめられていて、第一は「Make each program do one thing well」——各プログラムは一つのことを、うまくやれ。新しい仕事は、旧プログラムに「機能」を継ぎ足すかわりに、新しく書け、というものです。序文の署名は McIlroy、Pinson、Tague の三人。筆頭の McIlroy はパイプラインの発明者で、この箴言は今も彼の名とともに語られます。
いっそう広く流れている言い方もあります。1994 年、Peter Salus の『A Quarter Century of UNIX』は、McIlroy の言葉として三つの文を記しました。一つのことをして、それをうまくやるプログラムを書け。互いに協力するプログラムを書け。テキストストリームを扱うプログラムを書け——それが普遍のインターフェイスだから。cat、grep、wc。どれも小さな仕事しかしない道具です。けれどパイプでつなぐと、単独では決してできない仕事までやり遂げられます。
特例のためには破らない
規則は少ないほうが守られます。特例をひとつ開くごとに、規則はほどけていく。
特例は規則を破るほど特別ではない
Python の設計哲学は、The Zen of Python という 19 行の小さな詩にまとめられ、PEP 20 として公開されています。端末で import this と打てば、そのまま読めます。その第八行——特例は、規則を破るほど特別ではない。すぐ次の行では一歩引いて、それでも実用性は純粋さに勝る、と認めています。規則の壁には、換気の窓がひとつ開いています。
好きな理由は実利的です。規則が多ければ特例も増え、特例が増えた規則はやがて飾りになります。数を絞り、一本一本を本気にするほうが、かえって守られます。『いつも最もシンプルなものを選ぶ』という好みと、この取捨は同類です。複雑さが苦手なのではなく、特例の代金をあとで何度も払わないための選択なのです。
直せるほどシンプルに
直せるほどシンプルな設計が好きです。ごく普通の道具だけでも、もう一度動かせます。
普通の整備士が直せる飛行機
KISS の原則、Keep it simple, stupid。ロッキードのスカンクワークスで主任技師を務めたケリー・ジョンソンの言葉とされています——U-2 と SR-71 ブラックバードを生んだ場所です。いちばん有名なのはこんな逸話。彼は設計チームにひと握りの道具を渡し、こう言いました。設計中のこのジェット機は、戦場で普通の整備士がこの道具だけで直せるものでなければならない、と。stupid が指すのは人の愚かさではありません。物がどう壊れるかと、手元に残された道具の数、その釣り合いのことです。
出典には決め手がありません。1960 年にはアメリカ海軍に Project KISS という計画があり、1938 年の新聞にはさらに早い変種が見つかります。誰が先に言ったかより、大事なのはこちら。シンプルを、確かめられる基準にしたことです。造った人が感じる簡単さではなく、直す人の手元で試される。ものをシンプルに設計するのは、あとから触れるすべての人への配慮です。
自信に届いたら、やめる
テストは手段で、動くコードが納品物です。自信は必要なぶんだけ買えばいい。
報酬は、動くコードのために
Stack Overflow に How deep are your unit tests? という質問があります。いちばん上に選ばれた回答は、Kent Beck——テスト駆動開発の創始者、エクストリームプログラミングの生みの親——によるものでした。答えは率直です。私の報酬は動くコードに対して払われるのであって、テストに対しては払われない。だから私の哲学は、必要な水準の自信に届く最小限のテストにとどめる、というものです。括弧書きにはこうあります。その水準は業界標準より高いはずだが、慢心かもしれない、と。
続けて彼は自分のさじ加減を明かします。いつもは犯さない間違いにはテストを書かない。条件の複雑なロジックは見誤りやすいから念を入れる。チームで書くときは、みんなが間違えやすいところに重点を置く。彼にとってテストは、ひとつずつ勘定する予算です。書くたびに、確かな自信と引き換えになります。テスト駆動開発の創始者の口から出る「最小限でいい」。多く書く一本には、自分で理由が要るのです。
モードはいらない
良いインターフェイスに、見えない状態はいらない。指したところに、すぐ効く。これから何をするか、いちいち告げる必要はありません。
ナンバーは NO MODES
切り取り、コピー、貼り付け。Larry Tesler が同僚の Tim Mott と、Xerox PARC のエディタ Gypsy で生み出し実装した操作です。彼は生涯、「モード」のあるインターフェイスに反対しました。どこかへ出入りしてはじめて操作できる設計——キーを一度叩いて挿入モードに入り、文字を打ち、もう一度叩いて出る。彼の望んだモードレスなインターフェイスは、すべての操作がいつでも手もとにあります。車のナンバープレートは NOMODES、個人サイトのドメインは nomodes.com。
モードの欠点は、インターフェイスが見えない状態を覚えていることです。同じ操作をしても、効き方はいまどのモードに隠れているかで変わる。モードレスはその帳簿を破り捨てます。操作はその場で効き、出入りの儀式はない。PARC を出てからも、Tesler はこの主張を手放しませんでした。インターフェイスを作る人への、ひとつの戒めです。ユーザーに、自分の状態の帳簿を付けさせないこと。