プログラミングに関する次の 7 つの誤解を避けるように注意してください。-よくある問題-php.cn

自分の間違いについて公然と話す人をほとんど見かけません。

人は悪いことをすることから逃れることはできないのでしょうか？言うのは難しいですが、過去の間違いを振り返ることで、少なくとも短期的には、将来同じ間違いを犯すのを防ぐことができます。

モハメド・バロウマはプロプログラマー歴 5 年ですが、誰とでも同じように間違いを犯します。

彼はこう言いました:「通常、私は自分が何を間違ったかすぐには気づかない。物事の正しいやり方に触れた後でのみ、自分がどのような間違いを犯したかを知る。」

この記事は、彼の原文と合わせて、彼が犯した 7 つの大きな誤解を要約しています。

1. 適切な ORM

データアクセスレイヤーコードを使用しないと、常に混乱が生じ、退屈で退屈になります。残念ながら、これは最後まで発見されないことがよくあります。

モハメドとORMの関係は良好ではありません。 ORM、Object Relational Mappingは、Object Relational Modelの略称です。その機能は、プログラムが記述オブジェクトを操作することによってデータベースを操作できるように、リレーショナルデータベースとオブジェクトの間のマッピングを作成することです。

Mohamed が初めて単純な内部会計アプリケーションを作成したとき、基本プログラムを完成させるだけでも大量のコードを記述する必要があることがわかりました。そこで彼は ADO.NET に没頭し始め、目的を満たすために非常に特殊でカスタマイズされたテーブルスキーマを使用して自家製 ORM を手動で作成しました。

しばらくの間、この ORM は非常にうまく機能していました。数か月後まで、会社のビジネスニーズが変化し、テーブルスキーマ全体が変更されました。その後、ORM への変更が繰り返されました。。このプロセスは非常に面倒だったので、Mohamed は最終的に強く型指定されたデータセットアダプターを選択しました。

この問題は解決されましたが、作業を完了するためにより適切な ORM (NHibernate など) が見つかった場合、Mohamed は引き続きそうする義務があります。少なくともユーザーの数が増えたときは、データベース供給の変更について心配する必要はありません。

2. ジェネリックスの使い方を学んでいませんでした

プロのプログラマとしての Mohamed Barouma のキャリアは、Net 1.1 から始まりました。当時の Net 1.1 の主な問題は、ジェネリックスがサポートされていないことでした。つまり、厳密に型指定されたリストを持てず、退屈な ArrayList で妥協しなければならなかったのです。ただし、Arraylist を使用して Java コードで型変換とボックス化を実行すると、読み取りと書き込みが非常に困難になります。

したがって、Net 1.1 プログラマは CodeSmith を使用して、厳密に型指定されたコレクションリストを生成しました。

しかし、コードベースが増大するにつれて、カスタム生成されたリスト自体が管理不能な怪物になりました。目標を達成するために頻繁にオブジェクトを作成したりメソッドを呼び出したりする限り、後でコードを変更して混乱やエラーを引き起こすことになります。

Net 2.0 に切り替えて、保守が困難なカスタムコレクションリストをどんどん作成するのではなく、ジェネリックが利用可能になったらすぐに使い始めれば、すべてが解決します。

3. 「車輪の再発明」を決してあきらめないでください

これはよくあるテーマ、「車輪の再発明」(Reinvent The Wheel)です。新しいプログラマは常に、現在の実装が十分ではないため、すべてを最初から書き直す必要があると考えて、何度も「車輪の再発明」をするのが好きです。

なぜ「車輪を作る」というのでしょうか？本物の車輪が数千年前に丸いと決定されたのと同じように、多くのデータベースは長い間成熟して使いやすくなっていますが、「車輪を作る」ことに粘り強く取り組んでいるプログラマーは今でも無数にいます。ミミズは木に飛び込みますが、中にはユニークで革新的な人もいます。これが「車輪を作る」ことの不思議な魅力です。

その中には、Windows フォーム UI コントロールが単純すぎるため、独自の UI コントロールを書き直したいと考えている Mohamed さんもいます。結局、彼が作成した GUI ツールは、商用化された .Net UI 制御システムによって簡単に敗北し、新人プログラマーが作成した別の「車輪」がコードの海に沈んでしまいました。

4. あまり合理化されていないドキュメント

業界に入ったばかりの多くのプログラマーは、簡単な英語のコメントが使用されているため、最初はコードドキュメントが非常に優れていると感じるでしょう。やってる。しかし実際には、これらのドキュメントは通常、いくつかのコード変更の後、古くなったり時代遅れになったり、まったく間違っていたりして紙くずになります。

多くの場合、XML ドキュメントなどのコードドキュメントの作成に多くの時間を費やしますが、コードが変更されたときにドキュメントを更新する必要があることに気づきます。機能が変更されている可能性があるため。コードの更新は必要ですが、XML ドキュメントの更新は必要ありません。負担であり、時間がかかり、無駄です。

XML ドキュメントを繰り返し変更すると、最終的に人々は徐々に忍耐力を失い、別の作業に移ってしまいます。

5. 自動ビルドを使用しない

アプリケーションのデプロイとパッケージ化はプログラミングよりも比較的簡単であるため、多くの場合、優先順位が非常に低くなります。しかし間もなく、この粗末なビルドは動作しなくなり、さまざまな苦情を受けることになります。「何ができますか? パッチをくれませんか?」

「アイコンが表示されないのはなぜですか?」

その直後、雪崩のようにテーブルに電話がかかってきました。これはモハメッドにとって本当の経験であり、その日彼は疲れきっていました。プログラムのせいではなく、再展開と再パッケージングという気が遠くなるプロセスのせいでした。

これらすべてにおいて、自動化されたスクリプトを作成することである程度の時間を節約できた可能性があります。そうでないと、その後のデバッグに浪費される時間は、確実に節約できる時間の数倍になるでしょう。ソフトウェアはワンクリックで構築されるべきであり、そうでなければ無駄になります。

6. 視覚的な検査とデバッグに頼るのはやめられない

Visual Studio を使用すると、コードのデバッグや動的検査の実施が容易になり、フォームの作成も可能になります。出力の表示は非常に簡単です。しかし、デバッガに夢中になりすぎると、この利点が欠点に変わってしまいます。＃＃＃＃＃＃なぜ？アプリケーションが起動して実行されてから 45 分後にメソッドが呼び出される場合を想像してください。デバッグを開始する前に 45 分待つつもりですか?

それでは、アプリケーションを独立して呼び出すことができるコンポーネントに分割します。つまり、エラー出力を生成する入力値を準備し、そこからテストを開始できるということです。

7. 単体テストがない

多くのプログラマは、「私のアプリケーションは簡単なもので、手動テストで簡単にカバーできるでしょう。」と考えたかもしれません。大きくて複雑なもので、私のプログラムには向きません。"

ご想像のとおり、これにより、関心事の分離がなく、リファクタリングが難しく、完全に保守不可能なコードが直接作成されます。

「足の不気味さ」は、多くの初心者プログラマーの間でほぼ一般的な問題です。変更は破壊的な変更につながる可能性があるため、コードにわずかな変更を加えることさえ怖がります。その結果、最終的には手に負えなくなり、生じた問題は解決できませんでした。この従来のコードを扱うのは退屈でストレスがかかるだけでなく、精神的にもストレスがかかります。

しかし、単体テストを使用すると、コードの寿命を大幅に延ばすことができます。モハメドさんは、学校の初日から単体テストの「技術」を学び、単体テストを実践できることを望んでいますが、残念ながら学校ではそれを教えていません。

世の中には、数え切れないほどの試行錯誤から刺激的なイノベーションが生まれていますが、それでも基本的な間違いは避けなければなりません。あなたのプログラミング生活の中で、他にどんなばかばかしい「よくある誤解」に遭遇したことがありますか?それとも、不可解な「致命的な誤解」を引き起こしたのでしょうか？プログラミング学習の経験を共有するには、以下にメッセージを残してください。

参考文献: