私は30年以上プログラミングを続けています。 プログラミングの私の道は、マイクロプロセッサZ80および6502から、BASIC、アセンブリ、C、C ++などのプログラミング言語からTcl、Perl、Lisp、ML、occamまたはarc、Ruby、Goなどの最新のマシンにまで及びます。
プログラミングで学んだことのリストは次のとおりです。
0.プログラミングは、科学者やエンジニアではなく、職人の運命です
プログラミングは、科学や工学というよりも工芸に似ています。 これは、ツールを使用する能力で表されるスキルと経験の組み合わせです。 職人は必要なツールを選択し（必要に応じて独自のツールを作成し）、使用方法を学びます。
私にとって、これは工芸品です。 最高のプログラマーは、ビルダーや物理学者をつなぐというよりも、時計職人に近いと思います。 もちろん、このレッスンは外観上は論理や数学を使用するという点で科学や工学に似ていますが、ほとんどの場合、ツールを選択して何かを作成するだけです。
プログラミングが技術であるという事実を考慮すると、経験、ツール、直感がどれほど重要であるかがすぐに明らかになります。
1.誠実さが最善の戦略です
コードを書くとき、松葉杖を書いて、実際に何が起こっているのかを正しく理解せずにプログラムを動作させたいと思うことがあります。 古典的な例は、バグを魔法のように削除するという理由だけでAPI呼び出しを挿入することにした場合です。 または、printfを挿入した後、プログラムがクラッシュを停止します。
どちらの場合も、自己欺ceptionは明らかです。 「自分のプログラムがXを作成する理由を理解できますか？」と自問する必要があります。 そうでない場合は、トラブルを待ちます。 プログラマーとしてのあなたの仕事は、コンピューターが言われていることを正確に行うので、何をすべきかを理解することです。
誠実さには勤勉さが必要です。 あなたのプログラムが何をするのか、そして何故なのかについては、細心の注意を払わなければなりません。
2.単純化、単純化、単純化
トニー・ホアはかつて言った：「プログラミングには2つのアプローチがあります。 1つ目は、プログラムを非常に単純なものにして、明らかにエラーがないようにすることです。 そして2つ目は、明白なエラーがないように非常に複雑にすることです。 最初ははるかに複雑です。」
簡素化、リファクタリング、削除。
Hoarの声明を言い換えます。「大きくて複雑なプログラムはすべて、まったく同じことを行う小さくてエレガントなプログラムです。」
これは、「 疎結合レンガ 」の哲学に似ています。 強固なモノリスを構築するよりも、プログラムを互いに相互作用する小さな部分に分割する方が良い場合。 たとえば、UNIXはこのアプローチに一部成功している。
3.デバッガーは松葉杖、プロファイラー-いいえ
デバッガーはほとんど使用しません。 私は、何が起こっているのかを理解するために使用できるすべての必要な情報を記録するようにプログラムを作成します。 ほとんどの場合、デバッガーの助けを借りなくても、ログファイルのコードの何が問題なのかを理解できます。
デバッガーをめったに使用しないのは、考えることを少なくできるためです。 ほとんどの人は、バグを見つけると、デバッガーを開き、ブレークポイント、変数値、およびメモリーの亀裂に突入します。 このような強力なツールの呪文に簡単に当てはまるものはありますが、将来少し気をつければ、それは報われるでしょう。 プログラムが非常に複雑でデバッガが必要な場合は、ポイント2を再度参照してください。
（ただし、私の尊敬するプログラマーの1人であるJohn Osterhoutは、1日中Windowsデバッガーで過ごしているようです）。
プロファイラーに関しては、パフォーマンスを評価する必要がある場合に非常に役立ちます。 あなたはプロファイラーがあなたにどんな面白い結果を与えるのか疑問に思うことを決して止めません。
4.複製は支払う必要があります
繰り返してはいけません！ コードでは、すべてを一度だけ実行します。
これは段落番号2で理解されますが、特別な場合があります。 複製した小さなコードでも、1つのバージョンを変更し、2番目のバージョンの修正を忘れると、将来的に問題が発生します。
5.言語を判読できない
一部の人々はたった1つの言語に取りつかれ、この言語は何にでも適していると考えています。 そう考えるのは間違いです。 すべての機会に言語はありません。
主なことは、ツールのどの言語をどの問題に使用するかを理解することです。 したがって、より多くのツールを使用することをお勧めします。 さまざまな言語を試して、それらに何かを書いてください。
たとえば、PythonやMLを使用する場所をあまり使用する必要はないかもしれませんが、リストの内包表記を操作し、その力を感じます。 または、Goで遊んで、競争力のあるアプリケーションを操作する方法を確認してください。 または、Perlを使用して、本当に柔軟な文字列処理の力に感謝しますか。 最後に、動的Webページをすばやく作成するためのPHPを学びます。
私は言語間の戦争が嫌いです。 これらの戦争は敗者のためのものです。本質的に、議論することは何もないからです。 たとえば、私の手の中ではPHPは大惨事ですが、他の手ではナイチンゲールのように歌います。 同じことがC ++にも当てはまります。
6.プログラムをすぐに作成するよりも、プログラムを作成する方が簡単です
このアイテムは、アイテム番号2と密接に関連しています。 小さく始めてビルドします。 問題を解決するとき、最初から最後までアーキテクチャを設計するよりも、小さなブロックから開始する（場合によっては一部のスタブを作成する）方がはるかに簡単です。
アーキテクチャを最初から最後まで構築すると、1）間違ったことをする2）大きくて複雑なものになってしまい、変更が非常に困難になります。 一方、相互に作用する小さなブロックを使用する場合、最初に間違いを犯したことに気付いたときに、リファクタリングがより簡単になります。
その理由は、正しいアーキテクチャがどのように見えるかを見つける方法がないからです。 まれな場合にのみ、プログラムへの外部の影響が何であるかを言うことができます。 メールサーバーが処理する受信TCPトラフィックの性質、ユーザー数、またはスパムを聞いたことがないことを知っていると言えます。 何らかの方法で、すべての仮定を完全に破壊する外部からの何かがあります。これらの仮定が大規模で高度に接続された複雑なシステムに関するものである場合、大きな問題があります。
7.レイヤーの仕組みを学ぶ
何が起こっているのかを理解するために、CPUから使用する言語に移行することが不可欠だと思います。 レイヤーを理解することは非常に重要です（どのCコードがコンパイルされているか、Javaの場合はJVMとその動作を理解するかどうか）。
これは、パフォーマンスの問題やデバッグの問題に対処するときに非常に役立ちます。 私の記憶では、クライアントがクラッシュしたWindows 2000のスクリーンショットを私たちに送信すると、ケースがポップアップします。これは、小さなメモリとレジスタの状態を示しています。 クライアントによってインストールされたプログラムのバージョンがわかっていたため、このレポートでのみ、nullへのポインターを使用して問題を特定できました。最も重要なのはその原因です。
8.私はすべてを知るほど若くありません
学ぶべきことがたくさんあります。 一部の言語はほとんど知りませんが、それらを習得したいという願望があります（Erlang、Clojure）。 私は他のものを使用しましたが、それらをあまりよく知っていません（JavaScript）。 また、私が理解しにくいこともあります（モナド）。
PSテストについては何も言わなかったと非難されました。 私の意見では、しばらくの間対処しなければならないコードにはテストが必要であることを付け加える価値があります。 おそらく私はさらに30年をプログラムする必要があり、「単体テストはソフトウェアの品質を改善しますか？」という質問に対する答えを見つけるでしょう。 私は単体テストを使用して、または使用せずにコードを作成しましたが、正解はまだわかりませんが、単体テストを使用する傾向があります。
プログラミングで学んだこと
All Articles