若いプログラマーが学ぶべき 5 つの教訓

過去7において、私は十数名のソフトウェアインターンを率いて、何百人もの学生や卒業生のプロフィールを見てきました。彼らには学ばなければならないことがたくさんあると思います。おそらく、私は特定のテクノロジー、アルゴリズム、数学、またはその他の特定の形式の知識について話しているのではないか、と言うかもしれません。はい、これは学ぶべきことですが、最も重要なことではありません。彼らが学ぶべき最も重要なことは「自己規制」です。これらの規範は次のとおりです。できるだけ単純なコードを作成し、後で変更することでコードが複雑になる場合は、不要なコードを削除してコメントを追加してください。

私はこれらのインターン生にこれらの内容を学ぶよう勧めるのに多くの時間を費やしました。私はよく彼らに、優れた PHP プログラマーになる方法を尋ねます。通常、コードは明確で、理解しやすく、保守しやすいものでなければならないと答えます。これは確かに私が聞きたいことですが、実際にこれを一貫して実装できる若いプログラマーはほとんどいません。

これを心に留めておいてください。「自主規制」を理解する必要があり、一度「機能」したコードをすぐに忘れることはできません。すべての変数の名前が間違っていてもコードが完全に実行される場合、コードは耐えられないほど混乱してしまいます。関数コードを改善して簡潔なコードにすることは、短期的には効果がない可能性があります。元々動作していたコードは、クリーンアップ後も引き続き動作します。だからこそ「自主規制」が必要なのです。これが、インターンシップが非常に必要な理由です。良い上司はコードの品質に非常に重点を置いているため（たとえ「良いコード」の定義がプログラマーごとに異なるとしても）、そのためインターンや若手プログラマーはコードを何度も修正する必要があります。また。 。

私が挙げる次の例は、初心者プログラマがコードを書くときによく目にするものです:

その名前にふさわしくない関数/変数/クラス

これら関数とクラス 変数が実際に行うことは、その名前が示すものと一致しません。名前を一方的に見るのは正しいですが、現実となると、中には的外れなものさえあります。

たとえば、私の最後のインターンは、EditorGUI と EditorObjectCreatorGUI という 2 つのクラスを作成しました。編集インターフェイスを処理するコード。私が唖然としたのは、新しいオブジェクトの作成に使用されるのが EditorGUI であるのに対し、EditorObjectCreatorGUI はさまざまなオブジェクトを処理することによってのみナビゲートできることです。実はこの2つの意味は真逆なのです！コードは比較的単純ですが、逆の前提から始めたので理解するまでにかなり時間がかかりました。この状況の解決策は非常に簡単です。EditorObjectCreatorGUI の名前を EditorObjectNavigationGUI に変更するだけです。これにより、はるかに理解しやすくなります。

私はこれが起こるのをたくさん見てきました。これは、作業中にコードが進化するために発生します。名前を選択した時点では正しいかもしれませんが、コードを書き終わる頃にはその名前に値しない可能性があります。重要なのは、命名規則を常に念頭に置くことです。追加したものが関数名とクラス名に一致するかどうかを理解する必要があります。

混乱したクラス

もう1つの問題は、クラスが混乱していることです。クラスは無関係な処理をたくさん行っているためです。新しい機能を追加するのは簡単ですが、徐々にコードが肥大化し、さまざまな無関係な機能が随所に見られるようになります。場合によっては、肥大化はクラスのサイズを指すものではありません。クラスには数百行しかなくても、そのクラスに属さないコードが含まれている場合があります。

なぜこのようなことが起こるのでしょうか？たとえば、何らかの理由で、GUI クラスが利用可能なテクスチャを分析する必要があるとします (テクスチャを選択するボタンがある可能性があります)。この GUI クラスがこの分析の結果を必要とする唯一のクラスである場合、これを GUI クラスで行うのが合理的です。ただし、何らかの理由で、まったく関係のないゲームプレイ クラスにもこの情報が必要です。したがって、これらのテクスチャ クエリ情報を GUI クラスからゲームプレイ クラスに渡す必要があります。現時点では、GUI クラスは実際には TextureAnalyser クラスを含むため、実際には大きくなっています。解決策も簡単です。TextureAnalyser クラスを別のクラスに分割し、GUI クラスとゲームプレイ クラスの両方で使用できるようにします。

多くの人がこの経験則に疑問を抱いています。追加した機能が依然として元のクラスの名前と一致する場合はどうなるでしょうか?適合しない場合は、名前を変更するか、別のクラスに分割するか、別のクラスにコーディングする必要がありますか?

自分のクラスにぴったりの名前が思いつかないと、他の人に不快な思いをさせてしまいます。クラスの目的を名前で説明できない場合、クラスは乱雑に見えます。場合によっては、肥大化したクラスをいくつかの部分に分割し、それぞれに適切な名前を付ける必要があります。

大きすぎるクラス

これは、前の点 - 混乱を招くクラスと似ています: 多くのものが少しずつクラスに追加され、必然的に肥大化します。この場合、そのようなクラスはまだ意味がありますが、少し大きくなりすぎます。このような巨大なシステムは扱いにくいだけでなく、バ​​グも発生しやすくなります。同じプライベート メンバー変数を操作するには大量のコードを使用する必要があるため、いくつかの詳細を見落としがちです。

大きくなりすぎたクラスを分割するのは、実際には非常に退屈です。クラス内のコードが高度に絡み合っている場合、これは課題となる可能性があります。すでに機能しており、修正中は新しい機能を追加できないという事実と合わせて、大きすぎて厳密に規制できないクラスを分割することは選択肢ではないと言わざるを得ません。

Ronimo での一般的な経験によれば、クラスはコード 500 行以内、関数はコード 50 行以内に収めるのが最も適切です。ただし、場合によっては、これが実現不可能であったり、賢明ではなかったりします。しかし一般的に言えば、クラスや関数がその境界を超えると、それをリファクタリングして、より小さく管理しやすい部分に分割する方法を見つけることができます。

コードコメントについて

ほぼすべてのサンプルコードには、理由の説明なしにコメントされたコードスニペットが含まれています。このコードは修正する必要がありますか?古いコードは置き換えられましたか?なぜこのコードがそこに書かれているのでしょうか?コメントのないコードにはほとんど意味がないことは誰もが知っていますが、何らかの理由で多くの人がコードにコメントすることを忘れてしまいます。

並列ロジックとコードの重複

もう一つの問題は、複数のコードセグメントで同様のロジックが頻繁に見られることです。

例えば、「TreeBackground.dds」などのテクスチャの名前から、おおよその対象オブジェクトが分かります。テクスチャが木で使用できるかどうかを知るには、ファイル名が「tree」で始まるかどうかを確認します。 SDK を使用できる場合は、filename.beginsWith("tree") を使用して迅速に検出できます。ただ、このコードは非常に短いので、必要な場所を選択して直接コピーして貼り付けることがよくあります。もちろんこれはコードの重複であり、誰もが知っているようにコードの重複は避けるべきですが、コピーしたコードが短すぎると、それを忘れて自然に直接コピーしてしまいがちです。ここで直面する問題も明らかです。おそらく、テクスチャが木に適しているかどうかをチェックする方法を後で変更する必要があり、その場合は「ショットガン修正」(つまり、あらゆる箇所を修正する) 戦略を実装する必要があります。 1か所ずつ地面を補修していきます。

ここでの一般的なルールは、それが非常に特殊なコードである場合は、元のコードが非常に短く、関数を呼び出すために直接記述するよりも多くのコードが必要な場合でも、コードをコピーしないでください。関数。 。

上で議論した内容は非常に丁寧に説明されています。その多くは大学で学んだものでもあります。しかし、現在の課題は、消極的な遵守から積極的な記憶まで、段階的に習慣を身につける必要があることです。ロニモのインターンにとって最も重要なことは、知識を学ぶことではなく、自己規制を学ぶことである理由はここにあります。

Brothers IT Education のオリジナル PHP チュートリアル CD/「Essential PHP in Detail」を無料で入手 詳細については、公式 Web サイトのカスタマー サービスにお問い合わせください: http://www.lampbrother.net

PHP、Linux、HTML5 を学びます。 、UI、Android などのビデオチュートリアル (コースウェア + ノート + ビデオ)! Q2430675018 までお問い合わせください

イベントに参加して、Brothers のオリジナル ビデオ チュートリアル CD コレクションを受け取りましょう: http://www.lampbrother.net/newcd.html