頭の中にプログラムを保持する

2007年8月

優秀なプログラマーが自分のコードに集中して取り組むと、数学者が取り組んでいる問題を把握するのと同じように、自分のコードを頭の中で把握することができます。数学者は、小学生が教わるように紙の上で問題を解いて質問に答えることはありません。彼らは頭の中でより多くのことを行います。つまり、問題領域を十分に理解して、育った家の記憶を巡るのと同じように、問題領域を巡ることができるように努めます。最高のプログラミングも同じです。プログラム全体を頭の中で把握し、自由に操作することができます。

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

コードは、調査している問題に対するあなたの理解です。したがって、頭の中にコードがあるときだけ、問題を本当に理解できるのです。

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

優秀なプログラマーでも、自分が取り組んでいるプログラム全体を常に頭の中にロードしているわけではありません。しかし、それを助けるためにできることがいくつかあります。

**気を散らすものを避けてください。**気を散らすものは多くの種類の作業にとって良くありませんが、特にプログラミングにとっては良くありません。なぜなら、プログラマーは自分が処理できる詳細の限界で作業する傾向があるからです。

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

奇妙なことに、予定されている妨害は、予定外の妨害よりも悪い場合があります。1 時間後に会議があることがわかっている場合、難しい作業に取り掛かることさえありません。

**長時間作業する。**プログラムに取り組み始めるたびに固定コストがかかるため、短時間のセッションを何度も行うよりも、長時間のセッションを数回に分けて行う方が効率的です。もちろん、疲れて愚かな行動に出ることもあります。これは人によって異なります。36 時間連続でハッキングする人がいると聞いたことがありますが、私がこれまで管理できた最長時間は 18 時間程度で、12 時間以内のまとまった時間で作業するのが最も効果的です。

最適とは、あなたが体力的に耐えられる限界ではありません。プロジェクトを分割することには、利点とコストの両方があります。休憩後に問題に戻ると、無意識の心が答えを残して待っていることに気づくことがあります。

**簡潔な言語を使用します。**より強力なプログラミング言語はプログラムを短くします。そして、プログラマーは、少なくとも部分的には、プログラムの作成に使用している言語でプログラムについて考えているようです。言語が簡潔であればあるほど、プログラムは短くなり、読み込んで記憶に残すことが容易になります。

ボトムアッププログラミングと呼ばれるスタイルを使用すると、強力な言語の効果を高めることができます。ボトムアッププログラミングでは、プログラムを複数のレイヤーで記述し、下位のレイヤーが上位のレイヤーのプログラミング言語として機能します。これを正しく実行すれば、最上位のレイヤーだけを頭に入れておくだけで済みます。

**プログラムを書き直し続けてください。**プログラムを書き直すと、よりきれいな設計になることがよくあります。しかし、そうでなくても利点はあります。書き直すにはプログラムを完全に理解する必要があるため、書き直すよりもよい方法はないのです。

**読みやすいコードを書きましょう。**プログラマーなら誰でも、読みやすいコードを書くのは良いことだと知っています。しかし、最も重要な読者はあなた自身です。特に最初のうちはそうです。プロトタイプは自分自身との対話です。そして、自分のために書くときは、優先順位が異なります。他の人のために書く場合は、コードをあまり密集させたくないかもしれません。プログラムの一部は、入門書のように、内容を分散させると読みやすくなるかもしれません。一方、頭の中に再読み込みしやすいようにコードを書く場合は、簡潔さを追求するのが最善かもしれません。

**少人数のグループで作業します。**頭の中でプログラムを操作すると、自分のコードの端で視野が止まってしまいがちです。他の部分についてはよく理解できず、さらに重要なことに、自由に変更することはできません。したがって、プログラマーの数が少ないほど、プロジェクトはより完全に変化することができます。最初はよくあることですが、プログラマーが 1 人だけであれば、包括的な再設計を行うことができます。

**複数の人が同じコードを編集しないようにしてください。**他の人のコードを自分のコードほど理解することはできません。どれだけ徹底的に読んだとしても、読んだだけで、書いたわけではありません。そのため、コードが複数の作成者によって書かれた場合、1 人の作成者ほど理解できる人は誰もいません。

そしてもちろん、他の人が取り組んでいるものを安全に再設計することはできません。許可を求めなければならないというだけではありません。そのようなことを考えることさえできません。複数の作成者がいるコードを再設計することは、法律を変えるようなものです。一方、自分だけが管理するコードを再設計することは、あいまいなイメージの別の解釈を見るようなものです。

複数の人にプロジェクトに取り組んでもらいたい場合は、プロジェクトをコンポーネントに分割し、それぞれを 1 人の人に割り当てます。

最初は**小さく始めましょう。**プログラムは、慣れてくると頭の中で把握しやすくなります。十分に調べたと確信したら、各部分をブラックボックスとして扱うことができます。しかし、プロジェクトに取り組み始めたばかりのときは、すべてを把握する必要があります。問題が大きすぎると、完全に把握できない可能性があります。したがって、大きくて複雑なプログラムを書く必要がある場合、最初に行うべき最善の方法は、その仕様を書くことではなく、問題のサブセットを解決するプロトタイプを書くことです。計画の利点が何であれ、プログラムを頭の中で保持できることの利点の方がしばしば勝ります。

プログラマーが偶然に 8 つのポイントをすべて達成してしまうことがいかに多いかは驚くべきことです。誰かが新しいプロジェクトのアイデアを思いつきましたが、正式に認可されていないため、オフの時間に実行しなければなりません。その方が気が散ることがないので、生産性が高くなります。新しいプロジェクトに対する熱意に駆られた彼は、何時間も続けて作業します。最初は単なる実験なので、「プロダクション」言語ではなく、単なる「スクリプト」言語を使用します。これは実際にははるかに強力です。彼はプログラムを何度も完全に書き直します。公式プロジェクトでは正当化できませんが、これは愛情のこもった仕事であり、彼はそれを完璧にしたいと考えています。そして、彼以外に誰もそれを見ることはないので、自分へのメモ以外のコメントは省略します。彼は必然的に小さなグループで作業します。なぜなら、彼はまだ誰にもアイデアを伝えていないか、またはそれがあまりに見込みがないため、誰もそれに取り組むことを許可されていないからです。グループがあったとしても、複数の人が同じコードを編集することはできません。コードの変更が速すぎるため、それが不可能だからです。また、最初はアイデアが小さいため、プロジェクトは小規模に始まります。彼はただ、試してみたいクールなハックを持っているだけです。

さらに衝撃的なのは、公式に認可されたプロジェクトのうち、 8 つの点すべてを間違えているものの数です。実際、ほとんどの組織でソフトウェアが作成される方法を見ると、あたかも意図的に間違ったことをしようとしているかのようです。ある意味では、その通りです。組織というものが存在して以来、組織を定義する特性の 1 つは、個人を交換可能な部品として扱うことです。これは、戦争などの並列化しやすいタスクに適しています。歴史の大半において、よく訓練されたプロの兵士の軍隊は、どれほど勇敢であっても、個人の戦士の軍隊に勝つことは確実でした。しかし、アイデアを持つことは、並列化があまりできません。そして、プログラムとは、アイデアなのです。

組織が個人の才能に頼るという考えを嫌うというのは、単に真実というだけでなく、同義語でもあります。組織の定義には、そうしないことも含まれています。少なくとも、現在の組織の概念においてはそうです。

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

おそらく私たちができる最善のことは、組織のプログラミング部分を他の部分と異なる方法で機能させるような、ある種のハックです。おそらく、大企業にとって最適な解決策は、アイデアを社内で開発しようとせず、単にそれを購入することです。しかし、解決策が何になるかに関係なく、最初のステップは問題があることを認識することです。「ソフトウェア会社」というフレーズ自体に矛盾があります。2 つの単語は反対の方向に向かっています。組織はプログラマーが目指すものを妨げるように設計されているため、大規模な組織にいる優秀なプログラマーは誰でもそれに反抗するでしょう。

優秀なプログラマーはとにかく多くのことを成し遂げます。しかし、多くの場合、それは彼らを雇用する組織に対する反抗行為を実質的に必要とします。プログラマーの行動は彼らが行う仕事の要求によって動かされるということをもっと多くの人が理解すれば、おそらく助けになるでしょう。彼らが他のすべての義務を無視して長時間働き、最初に仕様を書かずにプログラミングに突入し、すでに機能しているコードを書き直すのは、彼らが無責任だからではありません。彼らが一人で仕事をすることを好むのは、彼らが非友好的だからではありません。または、挨拶するためにドアに顔を出した人にうなり声を上げるのも、彼らが非友好的だからではありません。この一見ランダムな迷惑な習慣の集まりには、1 つの説明があります。それは、頭の中にプログラムを保持する力です。

これを理解することが大企業に役立つかどうかは別として、競合他社には確実に役立ちます。大企業の最大の弱点は、個々のプログラマーに優れた仕事をさせないことです。ですから、あなたが小さなスタートアップ企業なら、ここが彼らを攻撃する場所です。1 つの大きな頭脳で解決しなければならない種類の問題に取り組んでください。

この原稿を読んでくださった Sam Altman、David Greenspan、Aaron Iba、Jessica Livingston、Robert Morris、Peter Norvig、Lisa Randall、Emmett Shear、Sergei Tsarev、Stephen Wolfram の皆様に感謝します。