生産工程で発生する問題は、徐々に中間層や経営層の注目を集めるようになりました。開発者であってもアーキテクトであっても、将来恥ずかしい状況に陥ることを避けるために、次の項目に十分な注意を払う必要があります。トラブルシューティングのメモとしても使用できます。
#1. プロパティ ファイルまたは XML ファイルで構成プロパティを外部化しないでください。たとえば、バッチ処理で使用されるスレッドの数は、プロパティ ファイルで構成できるように設定されていません。バッチ プログラムは、DEV 環境でも UAT (ユーザー受け入れテスト) 環境でもスムーズに実行できますが、PROD にデプロイされた後、より大きなデータ セットを処理するマルチスレッド プログラムとして使用されると、IOException がスローされます。これは、JDBC ドライバーのバージョンが異なるか、#2 で説明した問題が原因です。プロパティファイルでスレッド数を設定できる場合、シングルスレッドアプリケーションにするのが非常に簡単になります。問題を解決するためにアプリケーションのデプロイとテストを繰り返し行う必要はもうありません。この方法は、URL、サーバー、ポート番号などの設定にも適しています。
#2. テストで使用したデータセットのサイズが不適切です。たとえば、運用中の一般的なシナリオでは、テストには 1,000 ～ 2,000 のアカウントを使用する必要があります。パフォーマンス テストを行う場合、使用されるデータは切り取られていない本物である必要があります。実際の環境に近づけていないパフォーマンス テストでは、予測できないパフォーマンス、拡張性、およびマルチスレッドの問題が発生する可能性があります。より大きなデータセットを使用してアプリケーションをテストすることによってのみ、アプリケーションが適切に機能し、非機能属性の SLA (サービス レベル標準) を満たしていることを確認できます。
#3. アプリケーションで呼び出される外部サービスと内部サービスは信頼でき、常に利用できると単純に信じています。サービス呼び出しのタイムアウトと再試行を許可しないと、アプリケーションの安定性とパフォーマンスに悪影響を及ぼします。適切なサービス停止テストが必要です。今日のアプリケーションはほとんどが分散型でサービス指向であり、多数のネットワーク サービスを必要とするため、これは重要です。利用できないサービスを際限なく要求すると、アプリケーションに損害を与える可能性があります。ロード バランサーもテストして、各ノードのバランスを保つために適切に動作していることを確認する必要があります。
#4. 最低限のセキュリティ要件が守られていない。前述したように、ネットワーク サービスは遍在しているため、ハッカーがサービス拒否攻撃に悪用するのは簡単です。したがって、Secure Sockets Layer を使用する場合は、基本的な検証を完了し、Google Skipfish などのツールを使用して侵入テストを実行する必要があります。安全でないアプリケーションは、アプリケーション自体の安定性を脅かすだけでなく、顧客「A」が顧客「B」のデータを閲覧できる状況など、データの整合性の問題により企業の評判に悪影響を与える可能性もあります。
#5. ブラウザ間の互換性テストはありません。今日の Web アプリケーションは、ほとんどが JavaScript プログラミング言語と angular js などのフレームワークを使用するリッチなシングルページ アプリケーションです。構築した Web サイトがさまざまなデバイスやブラウザーでスムーズに動作するためには、対応するデザインを実装する必要があります。したがって、アプリがすべてのデバイスとブラウザーで動作することを確認するには、互換性をテストする必要があります。
#6. 頻繁に変更される可能性のあるビジネスルールを外部化しない。たとえば、税法、政府または業界関連の要件、分類法などです。 Drools などのエンジンを使用してビジネス ルールを処理すると、ビジネス ルールをデータベースまたは Excel に保存することで外部化できます。企業がこれらのビジネス ルールを習得すると、最小限の変更とテストで税法や関連要件に迅速に対応できます。
#7. 以下の書類は付属しておりません。
MindMap によって作成されたフォームである COS (Conditions of Satisfaction) に加えて、アジャイル開発には 2 つの主要なドキュメント フォーム (1 と 2) があります。
#8. 適切な災害復旧計画とシステム監視およびアーカイブ戦略が存在しない。プロジェクトの期限が近づくと、プロジェクトの展開を急ぐあまり、これらのことが見落とされることがよくあります。 Nagios と Splunk による適切なシステム監視が行われていないと、アプリケーションの安定性が脅かされるだけでなく、現在の診断や将来の改善の取り組みも妨げられます。
#9. データベース テーブルには、created_datetm、update_datetm、created_by、updated_by、timestamp などの便利な列設計がありません。また、「Y」または「deleted」列などの、順序付けられた削除レコード列も提供されません。 「N」。または、「アクティブ」または「非アクティブ」の「record_status」列を取得することもできます。
#10. 適切なリトレースメント計画の策定に失敗する。その結果、システムに障害が発生した場合、展開前の安定した状態にシステムを復元する方法はありません。この計画は、関連チームによって慎重に検討され、署名される必要があります。計画には、ソフトウェアの前のバージョンへのロールバック、データベースに挿入されたすべてのデータとプロパティ ファイル内のすべてのエントリの削除が含まれます。
#11. プロジェクトの開始前にキャパシティ計画を作成しない。現在、プラットフォームの要件を説明する場合、単に「Unix コンピューター、Oracle データベース サーバー、および JBoss アプリケーション サーバーが必要」と言うだけでは十分ではありません。リクエストは正確でなければなりません
以下の#12 は、「java.dzone」の「David DeCesare」によるコメントからのものです。
#12. 「仕事に最適なツールを使用しない」多くの場合、開発者は学習したい言語やツールを運用システムで使用します。通常、これは最良の選択肢ではありません。たとえば、すでに実際にはリレーショナルになっているデータに NoSQL データベースを使用します。どのツールを採用しても、今後 3 年から 5 年 (またはそれ以上) は製品を保守する必要があることに注意してください。
#13. 16 の主要な技術分野における十分な知識の不足。これらの領域には、1) 「同時実行の問題」、2) トランザクションの問題、3) パフォーマンスの問題の特定と修正が含まれます。多くの面接で、私は新しい契約を獲得するためにこれら 3 つの側面の知識を頼りにしました。