プログラムを頭の中に保持する | Paul Grahamのエッセイ

2007年8月

優れたプログラマーが自身のコードに集中して取り組むとき、数学者が取り組んでいる問題を頭の中で保持するのと同じように、コードを頭の中に保持することができる。数学者は、学校の子供たちが教わるように紙の上で問題を解くことで答えを出すわけではない。彼らは頭の中でより多くのことを行う：問題空間を十分に理解し、自分が育った家の記憶の中を歩き回るように、その周りを歩き回ることができるようになる。プログラミングも最高の状態では同じである。プログラム全体を頭の中に保持し、意のままに操作することができる。

これはプロジェクトの開始時に特に価値がある。なぜなら、最初のうちは、やっていることを変える能力が最も重要だからだ。問題を別の方法で解決するだけでなく、解決しようとしている問題自体を変えることさえできる。

あなたのコードは、あなたが探求している問題に対するあなたの理解である。だから、コードを頭の中に保持しているときだけ、あなたは本当に問題を理解していると言える。

プログラムを頭の中に入れるのは簡単ではない。プロジェクトを数ヶ月間放置すると、戻ってきたときに本当に理解するのに数日かかることがある。プログラムに積極的に取り組んでいるときでさえ、毎日仕事を始めるのに30分かかることがある。そしてそれは最良の場合である。典型的なオフィス環境で働く普通のプログラマーは、このモードに入ることはない。あるいは、もっと劇的に言えば、典型的なオフィス環境で働く普通のプログラマーは、彼らが解決している問題を本当に理解することはない。

最も優れたプログラマーでさえ、常に取り組んでいるプログラム全体を頭の中に保持しているわけではない。しかし、助けになることができることがいくつかある：

気を散らすものを避ける。 気を散らすものは多くの種類の仕事にとって悪いが、特にプログラミングにとっては悪い。なぜなら、プログラマーは扱える詳細の限界で操作する傾向があるからだ。

気を散らすものの危険性は、それがどれだけ長いかではなく、どれだけあなたの脳を混乱させるかによる。プログラマーはオフィスを離れてサンドイッチを買いに行っても、頭の中のコードを失うことはない。しかし、間違った種類の中断は30秒であなたの脳を消し去ることができる。

奇妙なことに、予定された気を散らすものは、予定されていないものよりも悪いかもしれない。1時間後に会議があると知っていると、難しい何かに取り掛かることさえ始めない。

長時間の作業を行う。 プログラムに取り掛かるたびに固定コストがかかるので、多くの短いセッションよりも、いくつかの長いセッションで作業する方が効率的である。もちろん、疲れて愚かになる時が来る。これは人によって異なる。36時間連続でハッキングする人も聞いたことがあるが、私がこれまでに管理できた最大は約18時間で、12時間以内の塊で作業するのが最善である。

最適なのは、物理的に耐えられる限界ではない。プロジェクトを分割することにはコストだけでなく利点もある。休息後に問題に戻ると、無意識の心が答えを待たせておいてくれたことがある。

簡潔な言語を使用する。 より強力なプログラミング言語はプログラムを短くする。そしてプログラマーは、少なくとも部分的には、使用している言語でプログラムを考えるようだ。言語が簡潔であればあるほど、プログラムは短くなり、頭の中にロードして保持するのが容易になる。

ボトムアッププログラミングと呼ばれるスタイルを使用することで、強力な言語の効果を拡大することができる。これは、プログラムを複数の層で書き、下位の層が上位の層のためのプログラミング言語として機能するようにするものである。これを正しく行えば、最上位の層だけを頭の中に保持すればよい。

プログラムを書き直し続ける。 プログラムを書き直すと、しばしばよりクリーンな設計が得られる。しかし、そうでなくても利点がある：プログラムを完全に理解しなければ書き直すことができないので、頭の中にロードするためのより良い方法はない。
再読み取り可能なコードを書く。 すべてのプログラマーは、読みやすいコードを書くことが良いことを知っている。しかし、最も重要な読者はあなた自身である。特に最初のうちは；プロトタイプは自分自身との会話である。そして、自分自身のために書くときには、異なる優先順位がある。他の人のために書いているときには、コードをあまりにも密集させたくないかもしれない。プログラムの一部は、導入の教科書のように、物事を広げると最も読みやすくなるかもしれない。一方、頭の中に再ロードしやすいようにコードを書くときには、簡潔さを追求するのが最善かもしれない。
小さなグループで作業する。 頭の中でプログラムを操作するとき、あなたの視界はあなたが所有するコードの端で止まる傾向がある。他の部分はそれほど理解しておらず、さらに重要なのは、自由に取り扱うことができない。だから、プログラマーの数が少なければ少ないほど、プロジェクトはより完全に変異することができる。最初によくあるように、プログラマーが一人だけなら、包括的な再設計を行うことができる。
複数の人が同じコードを編集しないようにする。 他人のコードを自分のコードほど理解することはない。どれだけ徹底的に読んだとしても、書いたわけではなく、読んだだけである。だから、もしコードが複数の著者によって書かれたなら、そのうちの誰も単一の著者が理解するほどには理解していない。

そしてもちろん、他の人が作業しているものを安全に再設計することはできない。許可を求めなければならないだけでなく、そんなことを考えることさえ許さない。複数の著者がいるコードを再設計するのは法律を変えるようなものだ；自分だけがコントロールするコードを再設計するのは、曖昧な画像の他の解釈を見るようなものだ。

もし複数の人をプロジェクトに取り組ませたいなら、それをコンポーネントに分割し、それぞれを一人に与える。

小さく始める。 プログラムは、慣れてくると頭の中に保持しやすくなる。完全に探求したと自信を持てたら、部分をブラックボックスとして扱い始めることができる。しかし、プロジェクトに最初に取り組み始めるときには、すべてを見なければならない。もし大きすぎる問題から始めると、それを完全に包含することはできないかもしれない。だから、大きくて複雑なプログラムを書く必要があるなら、それを始める最良の方法は、そのための仕様書を書くことではなく、問題の一部を解決するプロトタイプを書くことかもしれない。計画の利点が何であれ、プログラムを頭の中に保持できることの利点によってしばしば上回られる。

プログラマーが偶然にもこれら8つのポイントをすべて達成することがどれほど頻繁にあるかは驚くべきことである。誰かが新しいプロジェクトのアイデアを持っているが、それが正式に承認されていないため、オフの時間に行わなければならない—気を散らすものがないため、より生産的になることがある。新しいプロジェクトへの熱意に駆られて、彼は長時間連続してそれに取り組む。最初はただの実験なので、「本番」言語ではなく、単なる「スクリプト」言語を使用する—実際にははるかに強力である。彼はプログラムを何度も完全に書き直す；公式のプロジェクトでは正当化されないかもしれないが、これは愛の労働であり、完璧にしたいからだ。そして、自分以外には誰も見ないので、自分へのメモ以外のコメントは省略する。彼は必然的に小さなグループで作業する。なぜなら、まだ他の誰にもアイデアを話していないか、それがあまりにも有望に見えないので、他の誰もそれに取り組むことを許されていないからだ。グループがあっても、同じコードを複数の人が編集することはできない。なぜなら、それが可能になるには変化が速すぎるからだ。そしてプロジェクトは小さく始まる。なぜなら、アイデアは最初は小さいからだ；彼はただ試してみたいクールなハックを持っているだけだ。

さらに驚くべきは、公式に承認されたプロジェクトがこれら8つのことをすべて間違って行うことがどれほど頻繁にあるかである。実際、ほとんどの組織でソフトウェアが書かれる方法を見ると、彼らが意図的に間違ったことをしようとしているかのようだ。ある意味、彼らはそうしている。組織が存在して以来の定義的な品質の一つは、個人を交換可能な部品として扱うことである。これは、戦争のようなより並列化可能なタスクにはうまく機能する。歴史の大部分において、よく訓練された職業軍人の軍隊は、どれほど勇敢であっても、個人の戦士の軍隊を打ち負かすことができると期待されていた。しかし、アイデアを持つことはあまり並列化できない。そしてそれがプログラムである：アイデアである。

組織が個人の天才に依存するという考えを嫌うのは単に真実であるだけでなく、同語反復である。少なくとも私たちの現在の組織の概念の一部である。

おそらく、個人の努力を組み合わせるが、それらを交換可能であることを要求しない新しい種類の組織を定義することができるかもしれない。議論の余地はあるが、市場はそのような組織の形態であるかもしれないが、組織が不可能なときにデフォルトで得られるものとして、市場を退化したケースとして記述する方がより正確かもしれない。

おそらく私たちができる最善は、組織のプログラミング部分を他の部分とは異なるように動作させるような、何らかのハックである。大企業が社内でアイデアを開発しようとさえせず、単にそれらを買うことが最適な解決策かもしれない。しかし、解決策が何であれ、最初のステップは問題があることを認識することである。「ソフトウェア会社」という言葉自体に矛盾がある。この2つの言葉は反対の方向に引っ張っている。大組織の優れたプログラマーは、組織と対立することになる。なぜなら、組織はプログラマーが追求するものを防ぐように設計されているからだ。

優れたプログラマーはとにかく多くのことを成し遂げる。しかし、しばしばそれは彼らを雇っている組織に対する実質的な反逆行為を必要とする。もっと多くの人々が、プログラマーの行動が彼らが行う仕事の要求によって駆動されていることを理解すれば、助けになるかもしれない。彼らが無責任だから、他のすべての義務を無視して長時間の作業を行い、最初に仕様書を書く代わりに直接プログラミングに飛び込み、すでに動作しているコードを書き直すわけではない。彼らが不親切だから、一人で作業することを好んだり、挨拶に頭を突っ込んでくる人にうなるわけではない。この一見ランダムな迷惑な習慣の集まりには、一つの説明がある：プログラムを頭の中に保持する力である。

これを理解することが大組織に役立つかどうかは別として、確実に彼らの競争相手には役立つ。大企業の最も弱い点は、個々のプログラマーに素晴らしい仕事をさせないことである。だから、もしあなたが小さなスタートアップなら、ここが彼らを攻撃する場所である。一つの大きな脳で解決しなければならない種類の問題に取り組むのだ。

謝辞 Sam Altman、David Greenspan、Aaron Iba、Jessica Livingston、Robert Morris、Peter Norvig、Lisa Randall、Emmett Shear、Sergei Tsarev、Stephen Wolframに、この草稿を読んでくれたことに感謝する。