プログラマーの「気まぐれ」に関するPaul Grahamの記事の翻訳

労働者の要求に応じて、ポール・グラハムの記事 「ある人の頭の中でプログラムを保持する」の翻訳。



数学者が解く方程式を保持しているので、自分のプロジェクトに取り組んでいる優れたプログラマーは、それを完全に頭の中で保持できます。 子供たちは学校で教えられているので、数学者は紙の問題を解決しません。 代わりに、ほとんどの操作を頭の中で実行し、頭の中にイメージを作成します。これは、子供の頃を過ごした家のイメージを精神的にどのように想像できるかです。 プログラミングでは、すべてがまったく同じです。 現在のプロジェクト全体の特定のイメージを頭の中に作成し、あらゆる側面から慎重に検討することができます。



これは、最も重要なことの1つがあなたがしていることを変える能力である初期段階で最も頻繁に要求されます。 別の方法で問題を解決するだけでなく、その本質を変えてください。



しかし、プログラム全体を頭に収めることはそれほど簡単ではありません。 何らかの理由で数か月間コードにアクセスしていない場合、再度調査するのに数日かかることがあります。 積極的にプログラムに取り組んでいる場合でも、現在のタスクに取り組むためにあなた自身の意識を設定するのに毎朝最大30分かかることがあります。 そして、これは最良の場合のみです。 典型的なオフィスプログラマは、勤務時間の最後までこれを処理できません。 別の言語では、典型的なオフィスプログラマーは、解決しなければならないタスクを完全に理解することはありません。



優秀なプログラマーでさえ、プログラムの全体像を頭の中で知らないことがあります。 後者があなたに当てはまると思われる場合、この問題を解決する方法を以下に示します。



1.できるだけ気を散らさないでください。 気晴らしは多くの職業の人々の仕事に悪い役割を果たしますが、これは特に、考えられるすべての想像を超えた限界を超えて覚えなければならない詳細の量で作業するプログラマーに特に当てはまります。



注意を外部タスクに切り替えることの結果は、このタスクによる注意散漫の程度ではなく、その持続時間に依存しません。 そのため、たとえば、プログラマーはオフィスを離れ、ベンチに座ってサンドイッチを食べることができます。現時点では、作業中のプログラムから気を散らすことはありません。



プログラマーが通常は深刻なタスクを開始しない予定の状況よりもはるかに注意を払う予定外の状況は、特に有害です。



2.頑張ってください。 なぜなら 作業を開始する前に現在のタスクに関与する必要があるたびに、不必要なコストを最小限に抑える明白なソリューションは、大幅な中断のない長時間の作業です。 もちろん、延々と仕事をすることは不可能であり、ある瞬間、あなたは仕事から完全に「勉強」したことに気付くでしょう。 そのような状態の発症の速度は、特定の人の特性のみに依存します。 一日中36時間連続で働いていた人の話を聞きました。 私の最大時間は18時間ですが、連続して12時間以内で作業するときに最も快適に感じます。



最良の選択肢は、あなたの身体的能力とおそらく精神的能力が許すものではありません。 時々、仕事を休んでから戻ったとき、あなたの考えがプログラムコードとはかけ離れているように思われたが、脳によって解決された予期しない決定があなたにやってくる。



3.簡潔な言語で記述します。 強力なプログラミング言語は、プログラムを短縮します。 プログラマーは、少なくとも部分的には、作成された言語でプログラムを考えます。 言語が簡潔であればあるほど、プログラムは短くなり、イメージをメモリに復元しやすくなります。



下位層がベースを作成し、上位層のプログラムシェルを作成する抽象層で構成されるプログラムを作成すると、上向きプログラミングスタイルを使用してさらに大きな効果を得ることができます。 正しく実行すれば、最上位のレイヤーのみをメモリに保持できます。



4.プログラムを継続的に書き換えます。 コードを書き直すことで、アプリケーションアーキテクチャを改善できます。 そうでなくても、これには利点があります。プログラムを再度書き換えるには、その本質を完全に理解する必要があります。 そのため、プログラムのより正確な画像を頭の中で再現できます。



5.読みやすいコードを作成します。 すべてのプログラマーは、読みやすいコードの書き方を知っています。 しかし、あなた自身があなたのコードの最も重要な読者です。 特にプロジェクトの開始時。 将来のアプリケーションのプロトタイピングは、あなた自身との対話です。 自分で書くときは、優先順位がまったく異なります。 他の人のために書くとき、読みやすくするためにコードを多くの行に広げることができます。 メモリに簡単に復元できるようにコードを記述するときは、簡潔にすることをお勧めします。



6.小グループで作業します。 あなたの想像の中でプログラムを想像するとき、あなたはあなた自身のコード、あなたがあまりよく理解していない他の人によって書かれた部分に集中し、あなたはそれらをそれほど鮮明に想像することはできません。 したがって、プロジェクトで作業するプログラマが少なければ少ないほど、そのイメージをより全体的に提示することができます。 単独で作業する場合は、何でもできます。



7.複数の人が同じコードを編集することを許可しないでください。 私が言ったように、他人のコードだけでなく自分のコードも理解することはできません。 どれだけ注意深く読むかは関係ありません。ただ読むだけです-書きませんでした。 このように、コードの一部が複数の人によって書かれた場合、それらのどれもそれの完全で不可欠な表現を持っていません。



そしてもちろん、その中の何かを根本的に変えることはできません。 これには許可が必要なためではなく、単に想像することができないからです。 数人が書いたコードを再編成することは、宇宙の法則を再編成するようなものです。 独自のコードを再編成することは、頭の中のプログラムのあいまいなイメージの別の解釈にすぎません。



1つのプロジェクトを開発するのに複数の人が必要な場合は、プロジェクトを部分に分割し、プログラマーごとに1つ選択します。



8.小さく始めます。 プログラムを徹底的に研究すればするほど、精神的なイメージを作成しやすくなります。 完成したプログラムの個々の部分は、準備が整うまで実装の詳細に入らずに機能を実行するブラックボックスとして想像できます。 新しいプロジェクトを開始するときは、完全に頭の中に保管するだけです。 過度に複雑で膨大なタスクから始めると、おそらくそれを完全にカバーすることはできません。 同様のタスクに直面している場合は、正式な説明からではなく、サブタスクの1つを解決するプロトタイプの作成から始めてください。 計画の利点が何であれ、多くの場合、プロジェクト全体を頭の中に保持できることから得られる利点と比べてそれほど重要ではありません。



プログラマが自分の存在さえ知らずに8つのポイントすべてに固執する頻度は驚くべきことです。 誰かがアイデアを持っている場合、公式の管理サポートがないため、勤務時間外に対処する必要があります。 これにより、注意散漫がない場合の生産性が向上します。 プログラマーは純粋な熱意に駆られて、一晩中働いています。 なぜなら 彼のプロジェクトは純粋に実験的であり、企業標準の言語ではなく、簡潔なスクリプト言語でコードを記述しています。 彼はプログラムを再び完全に書き直しましたが、公式の開発であれば、上位の人々の承認は得られなかったでしょう。 しかし、この場合、これは個人的なプロジェクトであり、彼はそれを完璧にしたいと考えています。 彼以外の誰もコードを見ることができないことを考えると、彼は可能な限り簡潔かつ簡潔にコードを書くので、休憩後に簡単に取り組むことができます。 プロジェクトに参加しているのはごく少数であり、たとえ彼がそれを書いていて、1人以上であっても、 コードの変更は非常に高速で発生するため、他の人をプロジェクトに接続する方法はありません。

そして最後に、彼のアイデアはもともと本当に小さくて控えめだったので、彼は小さく始めます。



さらに驚くべきことは、8つの「ルール」すべてに何らかの形で違反している公式プロジェクトの数です。 実際、ほとんどの組織でソフトウェア開発の方法を見ると、彼らは故意にすべてを間違っているように見えることがわかります。 ある意味ではそうです。 組織の特徴の1つは、共通のメカニズムの交換可能な部分としての人々の認識です。 これは、たとえば戦争など、参加者間でタスクを並列化できるタスクに適しています。 歴史を通して、訓練されたmerc兵のよく組織された軍隊が、彼らがどんなに勇敢であっても、独立した戦士からなる軍隊に劣るという場合についての単一の言及はありません。 しかし、思考プロセスを人々の間であまり分散させることはできません。 そして、思考プロセスではないにしても、プログラミングとは何ですか。



組織が一人の独創的な従業員に依存する可能性を否定しているという主張は、完全に真実ではありません。 現在の理解では、定義上、組織はこれを許可すべきではありません。



おそらく、個々の従業員が交換可能である必要なく、個々の従業員の共同活動を使用する新しいタイプの組織を定義する必要があります。 ある程度、市場はそのような組織と呼ぶことができますが、より成功した説明は、市場を退化したケースとして説明することであり、組織が不適切な場合にそれ自体が起こります。



回避策を選択し、プログラマを他の従業員とは異なる方法で動作させる必要があるかもしれません。 おそらく大企業にとって最良の解決策は、アイデアを独力で生み出すことではなく、他の人からアイデアを購入することです。 どの解決策がそれぞれの特定の場合に適切であるかにかかわらず、最初に問題の存在を認識する必要があります。 「ソフトウェア開発会社」というフレーズ自体には矛盾が含まれています。 言葉は互いに反対方向に反発するようです。 優れたプログラマーは、大企業にいると間違った場所にいると感じるでしょう。なぜなら、 組織は、プログラマーが最も切望することを防ぐように設計されています。



優れたプログラマーは、何らかの形で多くのタスクに対処します。 しかし、多くの場合、このために彼は彼自身の会社に対する反乱をほとんど組織しなければなりません。 この動作は、その動作の要件そのものによるものです。 プログラマーはプログラミングに真剣に取り組み、他の責任を忘れ、仕様を記述せずにコードを書くことを急ぎ、無責任ではないために既存のコードを書き換えます。 彼らは一人で仕事をすることを好み、同僚の歓迎された頭に怒っており、友好的または閉鎖的ではないからではなく、出入口から定期的に現れます。 行動のこの一見ランダムな一連の習慣には、1つの理由があります。それは、プロジェクト全体に留意する必要があるということです。



これを理解することが大企業に役立つかどうかは、確かに彼らの競争相手を助けるでしょう。 そのような企業の最も弱い点は、プログラマーが重要な仕事をすることを許可しないことです。 あなたが小さな新興企業である場合、これを使用すると、それらを重要な競争にすることができます。 プログラマーの脳が全体として引き受けなければならないタスクの特徴を考慮してください。