バックエンド開発: 信頼性の高いインターフェイスを作成する方法

私は卒業して現在の会社に入社してから約 1 年が経ち、部門の新規プロジェクトの開発と立ち上げプロセスに 2 つのフェーズに分けて全面的に参加してきました。エンド開発者にとって最も苦痛なのは、リリースの前後です。オンライン化後のバグ修正段階では、さまざまな種類の突然の不可解なバグに直面し、めまいを感じ、混乱し、変更を加えるにつれてますます混乱を感じます。実験的なバグ修正が行われたり、1つのバグを修正した後に2つのバグが発生したりといった悲劇が起こることも多く、なぜ発売前にこんなにバグが多いのか不思議でなりません。

数日前に Douban の記事を読みましたが、まとめられていないものは経験ではなく、単なる経験です。プログラマは、ビジネスが来たらコードを書き、バグがあればバグを修正するだけでは技術の向上が難しく、毎回バグが多くなるのも当然です。長年働いている開発者もいますが、インターフェイスの数は時々 500 にも達し、初期段階でコードを書き、後期段階でバグを修正するのに忙しく、疲れてしまいます。

第一フェーズではビジネスやフレームワークに慣れ、エッジインターフェースを書き、第二フェーズでは小さなモジュールを担当してデータベースやプログラムの設計に挑戦しましたが、途中でつまずきました。昨日、オンラインがスムーズに進み、薄々感じていたので、簡単ではありますが、私や読者にインスピレーションを与えるかもしれない経験をいくつかまとめてみました。 (この記事では、基本レベルの単純なバグのみに焦点を当てており、高い同時実行性や大量のデータなどの複雑な問題は含まれていません)

1. インターフェイスにバグがあるのはなぜですか?

私が苦労して書いたインターフェイスは、テストしたときには問題なく動作しましたが、他の人が調整するとうまくいかないのはなぜでしょうか? ? （絵文字が入っているはずです。ご自身で判断してください。） もちろん、動作環境の問題も考えられますが、プログラムはサーバー上に一律に配置されており、通常はアーキテクトまたは運用保守の責任となります。プログラミング言語やオペレーティングシステムの問題については、今日はすべて考慮の対象外ですので、今日は自分で書いたバグのみを考慮します。

実際、実行中のプログラムには、リソース (CPU、メモリなど) アルゴリズム (プログラム実行プロセス) データ (ユーザー入力、データベース、サードパーティ インターフェイスなど) の 3 つだけが含まれます。通常、私たちはリソースは信頼できると考えていますが、バグは主に信頼性の低いアルゴリズムやデータの異常によって発生します。

さらに一歩進めて、マシンは厳密に 0/1 に従って命令を実行します。前回はアルゴリズムが正常に実行されましたが、今回はなぜ失敗したのでしょうか?本質的には、データが変更され、アルゴリズムがこの状況をカバーできなかったことが原因であるため、インターフェースの安定性を確保するには、データの信頼性の確保とアルゴリズムの堅牢性の確保という 2 つの側面を主に考慮します。アルゴリズムの堅牢性は、データのあらゆる状況において、この 2 つは切り離せないものであることを考慮する必要があります。

2. バグの少ないインターフェイスを作成するにはどうすればよいですか?

以前に分析したように、データの変更はインターフェイスのバグの最も一般的かつ本質的な原因です。その中で、データ変更の主な理由はユーザー入力です。プログラムにはユーザー入力が必要です。そうでないと意味がありません。

プログラミングの世界には、「ユーザー入力を決して信用してはいけない」という有名な格言があります。名前を期待する入力ボックスにユーザーが何を入力するかはわかりません。フロントエンドがフィルタリングしたからといって安心する必要はありません。ユーザーがクローラーやその他の手段を使用してインターフェイスに直接アクセスする可能性がある一方で、フロントエンドもユーザーであり、通信エラーも発生します。フロントエンドが間違った方法で呼び出しを行う可能性があります。インターフェイスであり、このエラーはより微妙な場合があります。

最初の提案: 形式やコンテンツを含むユーザー入力を厳密に検証します。

ユーザー入力を 1 つずつチェックするのが面倒で、機能が正常であれば問題ないと考えている人が多いことは承知していますが、これにより修正の経験が増えることがよくあります。バグは後ほど。テスト中にバグが報告されることがよくあります。何度も確認すると、フロントエンドが間違ったパラメーターを渡していたか、ユーザー入力を合理的に制限していなかったことがわかります。もちろん、非常に厳格になってフロントエンドに修正を行わせることもできますが、しかし、このプロセスはすでに多くの時間とエネルギーを無駄にしています。最初に自分でチェックして、適切なエラー メッセージを返すことをお勧めします。これにより、後で多くのエネルギーを節約できます。

これは、PHP などの動的言語に特に当てはまります。たとえば、Laravel フレームワークを使用する場合、最初にすべてのインターフェイスの入り口で $request->validate() を使用して、次の形式をチェックします。必要に応じて、時間範囲、要求されたデータが有効かどうかなど、入力内容をさらに検証するためのコードも記述されます。

2 番目の提案: ユーザーの面倒な操作、繰り返しの送信、遅延した送信を考慮する

繰り返しの送信は、ほとんどのバックエンドで考えられる状況であるはずです。インターフェイスの冪等性 一部のリソースは一度しか操作できず、検証が必要になる 実際には、繰り返し送信されるだけでなく、同じイベントが 2 人によって繰り返し処理される状況も同様です。

提出の遅れに関しては、実際には、テストでバグが報告されて初めて気づいた問題パターンでした。たとえば、get インターフェイスを通じて特定のリソースをユーザーに返す場合、ユーザーは post インターフェイスを通じてリソース ID を返し、変更を送信できます。リソース ID は独自の get インターフェイスによって返されるため、 ID は正当であり、厳密な閉ループを形成しているように見えますが、ユーザーがこのページに留まって送信が遅れた場合、この期間中にリソースの有効期限が切れたか、リソースが他の人によって変更され、ユーザーが正常に変更された可能性があります。不具合。実際、さらに詳しく考えてみると、これは同時実行性が高いシナリオにおけるリソース障害に似ていることがわかります。

3 番目の提案: データベースとサードパーティ インターフェイスの戻りデータを確認する

ユーザー入力に加えて、一般的なデータ ソースにはデータベースやサードパーティ インターフェイスが含まれます。比較的に、これらのデータ インターフェイスの信頼性は大幅に向上し、コンテンツ形式はより標準化されます。ただし、インターフェイスの安定性を確保するには、いくつかのテストを行うことが最善です。たとえば、データが空であることが多い場合は、プログラムの実行を直ちに終了し、適切な情報を廃棄する必要があります。

ちなみに、データベースに関しては、マスターとスレーブの遅延によるデータ更新の問題というバグにも遭遇したことがありますが、経験不足のため、この種の問題はあまり得意ではありません。だからもうそれについては書きません。

4 番目の提案: プログラム アルゴリズムは異常な状況を可能な限りカバーします

これは実際には最初の 3 つの補足です。一部の不正なユーザー入力については、次のようにすることができます。直接プログラムを中止してエラー メッセージを返しますが、状況によってはプログラムの実行を継続し、特別な処理を実行する必要がある場合があります。このような状況では、プログラム設計の初めにそれらを慎重に検討する必要があります。後で多くのことを行うことになります。バグが減り、メンテナンスが容易になります。

3. より効率的なインターフェイスの書き方

最後に、インターフェイスの効率とコードの品質についてもう少し考えてみましょう。

1. インターフェースの効率に影響を与える主な要因はデータベース操作です
私の限られた経験から言えば、インターフェース時間の長さは基本的に不合理なデータベース操作によるものです。パフォーマンス上の問題はありません。 for ループでデータベースにクエリを実行するコードをよく見かけますが、これは避けなければなりません。最初にすべてのデータを一度に取り出してから、それを 1 つずつ処理することができます。たとえば、すべてのデータベース操作をフレームワーク層で記録します。インターフェイスをデバッグするときに、すべてのデータベース操作とそれに対応する時間消費を確認できます。マージされたクエリはマージする必要があり、最適化された時間のかかるクエリはそれに応じて最適化する必要があります。 。

2. 例外、ログの合理的な使用法

この記事は主に PHP 言語に関するものです。歴史的な理由により、終了に return に依存するコードが多く見られました。このため、コードが複雑で呼び出しレベルが深い場合、保守が非常に困難になり、例外メカニズムに比べて直感的で利便性がはるかに劣ります。また、重要な情報は、後で問題の発見とデバッグを容易にするためにログに書き込む必要があり、無罪を証明するためにも使用できます。

3. コードは合理的に分割して抽象化する必要があります

コードをコピー アンド ペーストしないでください。繰り返される機能は分離する必要があります。要求の変更や拡張は合理的に考慮する必要があります。設計するときは小さく書く 焦点を絞った関数については、複雑な関数を一度に実装しないでください; この方法で書かれたコードは、変更、テスト、拡張が簡単です。私もこれが苦手で、オンラインになってからはコードがごちゃごちゃしていて、メンテナンスが大変です。次に、もっと考えて、もっと練習する必要があります。

4. 結論

あなたが書いたコードにバグがないことを願っています。

Laravel 関連の技術記事の詳細については、Laravel チュートリアル 列にアクセスして学習してください。

以上がバックエンド開発: 信頼性の高いインターフェイスを作成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。