頭の中でプログラムを保持する
Original2007年8月
自分のコードに集中して取り組む優れたプログラマーは、数学者が取り組む問題を頭の中で保持するのと同じように、それを頭の中に保持することができます。数学者は、学校で教えられるように紙の上で問題を解くのではありません。彼らは頭の中でより多くのことをします。つまり、自分が育った家の記憶を歩き回るように、問題空間を十分に理解し、それを操ることができるのです。プログラミングの最高の状態はまさにそれと同じです。あなたは全プログラムを頭の中に保持し、自由に操ることができるのです。
これは、プロジェクトの初期段階で特に価値があります。なぜなら、当初最も重要なのは、自分の行動を変更できることだからです。単に問題を別の方法で解決するだけでなく、解決しようとしている問題そのものを変更することができるのです。
あなたのコードは、探求している問題に対するあなたの理解です。ですから、コードを頭の中に持っているときにこそ、問題を本当に理解しているのです。
プログラムを頭の中に入れるのは簡単ではありません。数か月プロジェクトから離れていると、復帰したときにそれを本当に理解するのに数日かかることがあります。積極的にプログラムに取り組んでいる場合でも、1日の仕事を始めるときに30分かかってそれをロードすることがあります。そしてそれが最良の場合です。一般的なオフィス環境で働くプログラマーは、この状態に入ることはありません。あるいはより劇的に言えば、一般的なオフィス環境で働くプログラマーは、自分が解決しようとしている問題を本当に理解することはありません。
最高のプログラマーでさえ、常に自分が取り組んでいるプログラム全体を頭の中に保持しているわけではありません。しかし、それを助ける方法はあります:
注意散漫を避ける。 注意散漫は多くの種類の仕事に悪影響を及ぼしますが、特にプログラミングには悪影響を及ぼします。なぜなら、プログラマーは自分が扱える詳細の限界で操作しているからです。
注意散漫の危険性は、その長さではなく、脳をどの程度混乱させるかによって決まります。プログラマーはオフィスを出て、サンドイッチを買いに行くことができても、頭の中のコードを失うことはありません。しかし、間違った種類の割り込みは30秒でもあなたの頭を空っぽにしてしまうかもしれません。
奇妙なことに、予定された注意散漫のほうが、予定されていないものよりも悪い可能性があります。1時間後に会議があると知っていれば、難しいことに取り組み始めることさえしません。
長時間作業する。 プログラムに取り組み始めるたびに固定コストがかかるので、短い時間を多く使うよりも、長い時間を数回使うほうが効率的です。もちろん、疲れすぎて愚かになる時点がありますが、それはそれぞれ違います。36時間連続でハッキングしている人がいると聞きますが、私ができる最大は約18時間で、12時間以内の塊で最も良く働きます。
最適なのは、あなたが物理的に耐えられる限界ではありません。プロジェクトを分割することにはメリットとデメリットがあります。時には休憩を取った後に問題に戻ると、無意識の心が答えを待っていることがあります。
簡潔な言語を使う。 より強力なプログラミング言語はプログラムをより短くします。そしてプログラマーは、自分が使っているプログラミング言語の中でプログラムを少なくとも部分的に考えているようです。言語がより簡潔であれば、プログラムがより短くなり、頭の中に入れやすくなります。
強力な言語の効果を倍増させるには、下位から上位へのプログラミングスタイルを使うと良いでしょう。つまり、下位のレイヤーが上位のレイヤーのプログラミング言語として機能するように、複数のレイヤーでプログラムを書くのです。これを適切に行えば、最上位のレイヤーだけを頭の中に保持すればよいのです。
プログラムを繰り返し書き直す。 プログラムを書き直すと、しばしばより洗練された設計になります。しかし、そうでなくても利点があります。プログラム全体を完全に理解しなければ書き直せないので、それ以上ないほど確実にプログラムを頭の中に入れることができるのです。
読みやすいコードを書く。 すべてのプログラマーは、読みやすいコードを書くことが良いと知っています。しかし、最も重要な読者はあなた自身です。特に初期段階では、プロトタイプは自分との対話です。そして自分のために書く場合、優先事項が異なります。他の人のために書く場合は、コードを密にし過ぎるのは避けたいかもしれません。プログラムの一部は、入門書のように広げて書いたほうが読みやすいかもしれません。一方で、頭の中に再ロードしやすくするには、簡潔さを最優先するのが最善かもしれません。
小さなグループで作業する。 プログラムを頭の中で操作するとき、あなたの視野は自分の書いたコードの端で止まる傾向があります。他の部分はよく理解していないし、何より自由に変更することはできません。ですから、プログラマーの数が少ないほど、プロジェクト全体を変化させることができます。最初は1人のプログラマーであることが多いですが、そうすれば全面的な設計の変更ができます。
同じコードを複数の人が編集しないようにする。 自分のコードほど他人のコードは理解できません。どれだけ徹底的に読んでも、書いたわけではありません。ですから、複数の作者によってコードが書かれている場合、1人の作者ほど誰も理解していないのです。
そして当然ながら、他人が作業しているコードを安全に再設計することはできません。許可を求める必要があるだけでなく、そのようなことを考えさえしないのです。複数の作者のコードを再設計するのは、法律を変更するようなものです。自分だけが管理しているコードを再設計するのは、曖昧な画像の別の解釈を見つけるようなものです。
複数の人間にプロジェクトに取り組ませたい場合は、コンポーネントに分割し、それぞれに1人ずつ割り当てるのが良いでしょう。
小さく始める。 プロジェクトに慣れるにつれ、プログラムを頭の中に保持しやすくなります。完全に探求したと感じた部分は、ブラックボックスとして扱えるようになります。しかし、プロジェクトに初めて取り組むときは、すべてを見る必要があります。問題が大きすぎると、それを完全に理解することができないかもしれません。ですから、大きくて複雑なプログラムを書く必要がある場合、仕様書を書くのではなく、問題の一部分を解決するプロトタイプを書くのが最善の始め方かもしれません。計画には様々な利点がありますが、プログラムを頭の中に保持できることの利点に劣ることが多いのです。
プログラマーが偶然にも8つのポイントすべてに当てはまることがよくあるのは驚くべきことです。誰かが新しいプロジェクトのアイデアを持っているが、公式に承認されていないため、自由時間に行わざるを得ない - それが結果的により生産的になるのは、邪魔がないからです。新しいプロジェクトへの熱意に駆られ、長時間にわたって取り組みます。それが最初は単なる実験なので、「本番」言語ではなく「スクリプト」言語を使う - それが実は遥かに強力です。プログラムを何度も完全に書き換える; 公式プロジェクトでは正当化できませんが、これは愛情のこもった仕事で完璧を目指しています。そして誰も見ないので、自分用のメモ以外のコメントは省略します。 小さなグループで作業せざるを得ないのは、まだ他の人にアイデアを話していないか、あまりにも見込みがないと思われているため、他の人が参加できないからです。たとえグループがいても、コードが速すぎて変更が追いつかないため、複数人で編集することはできません。そしてプロジェクトは最初は小さいのは、アイデア自体が最初は小さいからです; 試してみたいクールなハックがあるだけです。
公式に承認されたプロジェクトでさえ、8つのことすべてを間違えてしまうのはさらに驚くべきことです。実際、ほとんどの組織でソフトウェアが書かれる方法を見ると、わざと間違ったことをしているかのようです。ある意味では、そうしているのです。組織の定義的特徴の1つは、個人を互換可能な部品として扱うことです。これは戦争のような並列化しやすい仕事には適していますが、アイデアを生み出すことはそうではありません。そして、プログラムとはアイデアなのです。
組織が個人の天才性に依存することを嫌うのは単なる真理ではなく、定義上そうなのです。少なくとも、現在の組織の概念では。
個人の努力を組み合わせつつ、彼らを互換可能なものとして扱わない新しい種類の組織を定義できるかもしれません。市場がそのような組織形態と言えるかもしれませんが、組織化が不可能な場合のデフォルトとして捉えるのがより正確かもしれません。
おそらく最善のアプローチは、組織の中でプログラミングの部分だけを他とは異なる方法で機能させるというようなハックです。大企業がアイデアを自社内で開発するのではなく、単に[1]それらを買い取るのが最適な解決策かもしれません。しかし、解決策がどうあれ、まずは問題があることを認識することが重要です。「ソフトウェア企業」という言葉自体に矛盾があります。2つの言葉は逆方向を向いています。大企業に所属する優秀なプログラマーは、組織に対して対立せざるを得ません。なぜなら、組織はプログラマーが目指すものを阻害するように設計されているからです。
優秀なプログラマーは、それでも多くのことを成し遂げます。 しかし、しばしば雇用主である組織に対して反抗的にならざるを得ません。プログラマーの行動は、彼らの仕事の要求によって駆動されていることを理解すれば、状況が改善されるかもしれません。長時間の集中的な作業中に他の義務を無視したり、仕様を書く前に直接プログラミングに取り掛かったり、すでに動作しているコードを書き換えたりするのは、彼らが無責任だからではありません。一人で作業し、ドアを開けて挨拶する人を怒鳴るのも、同じ理由です。これらの見かけ上無関係な厄介な癖には、1つの説明があります。それは、プログラムを頭の中に保持する力なのです。
この理解が大企業の助けにならなくても、競争相手の助けにはなるでしょう。大企業の最も弱い点は、個々のプログラマーが優れた仕事をすることを許さないことです。だから、あなたが小さなスタートアップなら、ここが攻撃すべき場所です。1人の頭の中で解決しなければならない問題に取り組むのです。