Web開発で注意すべき18の重大な間違い

過去数年間、私はいくつかの興味深いプロジェクトに参加し、独自に開発、アップグレード、リファクタリング、新機能の開発を完了する機会がありました。

この記事では、PHP プログラマーが Web 開発において、特に中規模および大規模なプロジェクトを扱うときに見落としがちないくつかの重要な間違いをまとめています。典型的なエラーには、さまざまな開発環境を区別できないことや、キャッシュとバックアップの使用に失敗することが含まれます。

以下では例として PHP を使用しますが、その中心的な考え方はすべての Web プログラマーに適用できます。

アプリケーション レベルのエラー

1. 開発段階ではエラー報告がオフになっています

PHP にはさまざまなレベルのエラー報告機能があるため、開発段階ではすべてを有効にする必要があります。

エラーが起こらないと考えると、現実の世界ではエラーは避けられないものになります。 error_reporting と display_error はまったく異なる 2 つのメソッドです。 error_reporting () はエラー レベルを設定し、display_errors はエラー情報を出力するかどうかを設定します。

開発段階では、エラー報告レベルを次の設定のように最高レベルに設定する必要があります: error_reporting (E_ALL) および ini_set ('display_errors', true); p>

多くのプログラマはエラーが発生することを知っていますが、エラーを非表示にすることを選択します。早く家に帰って寝てください。将来さらに重大な間違いが起こるとは、彼らはほとんど知りませんでした。

3. コードのどこにも使用ログがありません

ソフトウェア開発の初めに使用ログを覚えておく必要があります。ログを補うことはできません。プロジェクトが終了するまで機能します。多くのプログラマーは何らかの方法でログを記録しますが、実際にログを使用して異常な情報を記録できる人はほとんどいません。誰もチェックしないログ システムは何に役立つのでしょうか。

4. キャッシュは使用されません

アプリケーション システムでは、サーバー側、アプリケーション側、データベース側など、複数のシステム レベルでキャッシュを使用できます。待って。ログと同様に、キャッシュは最初からシステムに適用する必要があります。開発中はキャッシュを無効にし、製品リリース後にキャッシュを有効にすることができます。

5. ベスト プラクティスと設計パターンを放棄する

独自のパスワード暗号化アルゴリズムを使用している人を何人見たことがありますか?申し訳ありませんが、彼らは自分たちの方がよく知っているだろうと考えているため、たくさんいます。

ベスト プラクティスとデザイン パターンは先人によって作成されており、多くの場合、私たち開発者はこれらのデザイン パターンに習熟し、合理的に使用するだけで済みます。一部の暗号化アルゴリズムなど、プロジェクトに適用するだけです。

6. 自動テストは使用されません

テストは、ログと同様に、誰も管理および使用しないと役に立ちません。 。

テスト プロジェクトの実行は面倒な作業です。幸いなことに、自動テストの実現に役立つ一連のツールがあります。 PHP 開発には、Jenkins と呼ばれる優れたテスト ツールがあり、非常に便利です。

7. コードレビューはありません

各メンバーが独自の作業習慣や方法を持っているため、適切な仕様がなければプロジェクト開発は非常に困難です。多くの回り道をすることになる。

単体テストと同じように、チームのメンバー全員が互いのコードをレビューする必要があります。そうすることで、プロジェクトをよりクリーンで一貫性のあるものにすることができます。

8. プログラミングは理想的な状況のみを考慮します

顧客に引き渡された後、自分や他の人のコードで問題や混乱に遭遇したことがありますか?もちろんそうではありませんでした。

この状況は、開発者が怠惰で理想的な状況だけを考えているために頻繁に発生し、データベースのクラッシュ、PHP の致命的なエラー、さらにはサーバーのハッキングにつながる可能性があります。コードを記述するとき、プログラマは最良のシナリオだけでなく、最悪のシナリオも考慮する必要があります。包括的に考えることによってのみ、コードはすべての状況をカバーすることができます。

9. オブジェクト指向プログラミングのアイデアを正しく適用できない

ほとんどの PHP 初心者は、オブジェクト指向のアイデアをコードに使用しません。はじめに理解してください

もちろん、オブジェクト指向の概念は、単にいくつかのクラスをまとめることではありません

これらは OOP の最も基本的な概念です。開発者がオブジェクト指向設計パターンを正しく使用すると、よりクリーンでスケーラブルなコードを作成できるようになります。

10. 「オンザフライ」プログラミング

ほとんどの開発者は次のような状況に遭遇します。できるだけ早く」ということで、ソース コードにいくつかの新しい関数を追加し、実行中のサーバーに直接アップロードします。このプログラミング方法を「オンザフライ」プログラミングと呼びます。

ソフトウェア、特に中規模および大規模プロジェクトを開発するときは、ワークフローに従って分析、プログラミング、リリースする必要があります。これにより、将来のソフトウェアのバグが大幅に減少します。この「フライトモード」はお勧めできません。

データベースレベルのエラー

11. データベースの読み取りと書き込みを分離しない

各プログラマはシステムのスケーラビリティを考慮する必要があります。99% の場合、システムはそれほど大量のトラフィックがないため、拡張を考慮する必要はありません。

データベースの読み取りと書き込みを分離する必要があるのはなぜですか?

どのシステムでも、大規模なトラフィックの影響で最初に障害が発生するのはデータベースです。そのため、ほとんどの場合、トラフィックを分散するために複数のデータベースを使用し、開発者はマスター/スレーブ モードまたはマスター/マスター モードを使用することがよくあります。マスター/スレーブは最も一般的なデータベース プレッシャー共有モードで、指定された select ステートメントを各スレーブ サーバーにルーティングするため、マスター サーバーのプレッシャーが大幅に軽減されます。

12. コードは 1 つのデータベースにのみ接続できます

これは前のエラーとよく似ていますが、開発者は何らかの理由で複数のデータベースに接続する必要がある場合があります。たとえば、ユーザー ログ、アクティビティ情報ストリーム、リアルタイム データ分析などの高負荷データを別のデータベースに配置して、メイン データベースへの負担を軽減します。

13. データベースの脆弱性の検出に失敗する

データベースの脆弱性を検出できない場合、それはほとんどのハッカーに対してサーバーの扉を開くことと同じです。

多くの脆弱性の中で、データベースの脆弱性が最も脆弱であり、最も一般的なのは SQL インジェクションです。したがって、データベースの脆弱性検出を定期的に行う必要があります。

14. データ テーブルにはインデックスがありません

適切なインデックスは各テーブルのパフォーマンスを向上させることができます。この記事では、インデックスの作成方法とインデックスをいつ作成するかを説明しています。

15. トランザクションメカニズムは使用されません

データの整合性においてエラーが発生すると、システム全体が崩壊してしまいます。修理する。データベース トランザクション メカニズムを適切に使用すると、この問題は効果的に解決されます。たとえば、ユーザー データを保存する場合、テーブル 1 には電子メール、ユーザー名、パスワードがあり、テーブル 2 には名、姓、性別、年齢が含まれます。トランザクションを使用すると、2 つのテーブルを更新するときにデータが同時に更新されるか、または同時に更新されないようにできます。

16. 機密データは暗号化されません

 

  PHP5.5 は次のように使用されるハッシュ暗号化方式を提供します。 span> 

$hash = password_hash ( $password, PASSWORD_BCRYPT );

17. バックアップがありません

このような状況に遭遇してバックアップがなければ、すべてが終わってしまいます。