John Graham-Cumming によるオリジナル記事 。
著者の許可を得て翻訳および公開。
私は30年以上プログラミングを行ってきました。すでに廃止されたマシン（Z80および6502プロセッサ）からBASIC、アセンブラ、C、C ++、Tcl、Perl、Lisp、ML、occam、arc、Ruby、Go、他の多くの。
以下は私が学んだことのリストです。
0.プログラミングは科学であり、工学ではなく技術です
プログラミングは、科学や工学よりもはるかに工芸に近いものです。 ツールの助けを借りて表現されたスキルと経験の組み合わせです。 開発者は必要なツールを選択し（独自のツールを作成することもあります）、作成プロセスで使用することを学びます。
これはクラフトのようです。 最高のプログラマーは、ビルダーや物理学者というよりも時計職人のように見えると思います。 もちろん、プログラミングは、論理と数学の使用のために科学と工学に似ていますが、核となるのはツールの使用とそれらの助けを借りた何かの作成です。
これはクラフトであるため、経験、ツール、直感が重要であることは容易に理解できます。
1.誠実さが主なルールです
コードを書く過程で、実際に何が起こっているのかを理解せずに、プログラムが動作して実行できるかどうかを実験してみてください。 古典的な例はAPI呼び出しです。これは、魔法のようにバグを取り除くか、printfを追加することができ、その結果、プログラムのクラッシュが停止するため、終了することにします。
どちらの例も不正直です。 「自分のプログラムがXを作成する理由を理解できますか？」 わからない場合は、後で問題が発生します。 何が起こっているのかを知ることはプログラマーの責任です。なぜなら、コンピューターは、注文したとおりではなく、注文どおりに動作するからです。
誠実さには厳格な態度が必要です。 あなたのプログラムが何をするのか、そしてその理由を知っていることを確認する必要があります。
2.単純化、単純化、単純化
Tony Hoarは次のように述べています。「システムを設計するには2つの方法があります。 1つは、明らかに欠陥がないように非常に単純にすることであり、2つ目は、明白な欠陥がないように非常に複雑にすることです。 最初の方法ははるかに困難です。」
簡素化、書き換え、削除。
Hoarを言い換えると、「すべての大規模で複雑なプログラムの中には、大規模なプログラムと同じように機能し、適切に機能する小規模でエレガントなプログラムがあります」と言います。
「互いに疎結合されている小さな要素」アプローチが関連しています。 巨大なモノリシックな全体を作成するよりも、相互に作用する小さなパーツで構成されるプログラムを設計する方が適切です。 これがUNIXが成功した理由です。
3.デバッガーは時々害を及ぼすが、プロファイラーは決して
デバッガーはほとんど使用しません。 私のプログラムは雑誌を作成し、私のプログラムが何をするかを知っています。 通常、デバッガーの助けを借りずに、ログからコードの何が問題なのかを理解できます。
デバッガーを使用しない理由は、デバッガーが私を怠zyにするという私の信念です。 エラーを発見すると、多くの開発者がデバッガーを起動し、ブレークポイントを設定して、メモリーまたは変数の値を調べます。 このような強力なツールの魅力に屈することは簡単ですが、不適切な思考は時間の大幅な損失につながります。 プログラムが非常に複雑でデバッガが必要な場合は、セクション2を参照してください
（注：上記のすべてにもかかわらず、私が尊敬するプログラマーの1人であるJohn Osterhutは、何日もWindowsデバッガーに座っているようです）。
一方、プロファイラーは、パフォーマンスに対処する必要がある場合に必要です。 プロファイラーがあなたに何を伝えることができるのか疑問に思うことは決してありません。
4.複製されたコードはあなたの足を置き換えます
繰り返さないでください。 コードで一度すべてを行います。
このレッスンはクレーム2に関連していますが、これは特別なケースです。 複製されたコードの単純な部分でさえ、後で1つの場所で「修正」し、別の場所でそれを忘れると、問題が発生します。
5.プログラミング言語に慣れない
一部の人々は特定のプログラミング言語に夢中になっており、それらのみを使用することを余儀なくされています。 これは間違いです。 すべてのタスクに適した言語はありません。
特定の問題に使用するツールキットの言語を知ることが重要です。 そして、より多くのツールを持っている方が良いです。 さまざまな言語を試して、それらを実践してください。
たとえば、PythonやMLは必要ありませんが、リスト式を試して、その威力を確認できます。 または、Goで「遊んで」、マルチスレッドでどのように機能するかを確認してください。 または、Perlを使用して、Perlが文字列でどのように柔軟に機能するかを確認してください。 または、PHPを使用して動的なWebページをすばやく作成します。
私は言語戦争が好きではありません。 彼らは間違ったことについて議論するので、彼らは多くの敗者です。 私にとって、PHPは制御不可能なツールであり、他の人の手で驚くほどうまく機能します。 C ++についても同じことが言えます。
6.プログラムを構築するよりも、プログラムを成長させる方が簡単です。
このルールはアイテム2に関連しています。 小さく始めて、徐々に成長します。 問題を解決するとき、すぐに巨大なシステムを思い付くよりも、その小さな部分から始めるのが最も簡単です（おそらく、一時的なスタブを使用するか、不足している部分をエミュレートする）。
システム全体をすぐに作成する場合：（a）それを理解していない、（b）変更するのが非常に難しい迷路を思い付く。 一方、相互に作用する小さな要素が多数ある場合、最初のどこかで間違いを犯したことに気付いた場合、リファクタリングが容易になります。
その理由は、本当に正しいアーキテクチャがどうあるべきかを決して知らないからです。 外部の影響がプログラムに与える影響を予測することは非常にまれです。 TCPトラフィックがメールサーバーまたは宛先の数をどのように流れるかを知っているか、スパムを聞いたことがないかもしれません。 前提に違反するものが常に存在し、それらが巨大で混乱し、複雑なプログラムを形成する場合、それはあなたが深刻な問題に直面していることを意味します。
7.アプリケーション層を調べる
中央処理装置から始めて、使用する言語で終わる、プログラムで何が起こっているのかを理解することは非常に重要だと思います。 アプリケーション層を理解することが重要です（たとえば、コンパイルされたCコードに何が起こるか、Java仮想マシンがどのように機能するかを理解する）。
これは、パフォーマンスの問題を解決する必要があるとき、およびデバッグするときに非常に役立ちます。 私の会社のクライアントの1つがWindows 2000のエラーのスクリーンショットを送信し、小さなメモリとレジスタの状態を示したケースを覚えています。 この情報のみを使用し、プログラムのバージョンを知ることで、nullポインターとその原因に関する問題を検出することができました。
8.私はすべてを知るほど若くありません
私はまだ学ぶことがたくさんあります。 私がほとんど動作しなかった言語がありますが、（Erlang、Clojure）を希望します。 私が「遊んだ」言語はありますが、私はそれらの言語を十分に理解していません（JavaScript）、そして私がほとんど理解できないアイデアもあります（モナド）。
PS：彼らは、私がテストについて言及しなかったことを私に指摘しました。 追加する価値があります。長期間使用されるコードにはテストが重要であると確信しています。 おそらく私がさらに30年間プログラミングを行うとしたら、「単体テストはプログラムの品質を向上させるのでしょうか？」という質問に対する答えが得られるでしょう。 私はテスト付きでテストなしでコードを書きましたが、正確な答えを知っているかどうかはまだわかりませんが、単体テストはプラスの効果があると信じています。
翻訳：30年間のプログラミングで学んだこと
All Articles