Java ベテランが注意すべき 13 の間違い

生産過程で発生する問題は、徐々に中間管理職や上層部の注目を集めています。開発者であってもアーキテクトであっても、将来恥ずかしい状況を避けるために、次の項目に十分な注意を払う必要があります。トラブルシューティングのメモとしても使用できます。

#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. 次のドキュメントは提供されていません

単体テスト ドキュメントを作成し、適切なコード カバレッジを持たせるようにしてください。

統合テスト。

包括的または百科事典的なページには、クラス、スクリプト、構成ファイルなどのすべてのソフトウェア コンポーネントがリストされており、これらのコンポーネントは変更されるか、新しく作成されます。

高レベルの概念図は、すべてのコンポーネント、相互作用、構造を示しています。

基本ドキュメントでは、開発者に「データソースに関する詳細な情報に基づいて開発環境を構築する方法」を説明します。

マインドマップで作成されたフォームである COS (Conditions of Satisfaction) の他に、アジャイル開発には 1 と 2 の 2 つの主要なドキュメント フォームがあります。

#8. 適切な災害復旧計画やシステムの監視とアーカイブ戦略がない。プロジェクトの期限が近づくと、プロジェクトの展開を急ぐあまり、これらのことが見落とされることがよくあります。 Nagios と Splunk を使用して適切なシステム監視を設定しないと、アプリケーションの安定性が脅かされるだけでなく、現在の診断や将来の改善の取り組みが妨げられます。

#9. created_datetm、update_datetm、created_by、updated_by、timestamp などのデータベース テーブルには便利な列設計がありません。また、'Y' または ' を受け取ることができる 'deleted' などの規則的な削除レコード列も提供されません。 N'. 'アクティブまたは非アクティブの列または 'record_status' 列。

#10. 適切なリトレースメント計画の策定に失敗する。その結果、システムに障害が発生した場合、展開前の安定した状態にシステムを復元する方法はありません。この計画は、関連チームによって慎重に検討され、署名される必要があります。計画には、ソフトウェアの前のバージョンへのロールバック、データベースに挿入されたすべてのデータとプロパティ ファイル内のすべてのエントリの削除が含まれます。

#11. プロジェクトの開始前にキャパシティ計画は策定されませんでした。現在、プラットフォームの要件を述べる場合、単に「Unix マシン、Oracle データベース サーバー、および JBoss アプリケーション サーバーが必要」と言うだけでは十分ではありません。要件は、オペレーティング システムや JVM などの

特定のバージョンに対して正確である必要があります。

メモリの量 (物理メモリ、JVM ヒープ メモリ、JVM スタック メモリ、JVM 永続世代スペースを含む)。

CPU (コア数)。

ロードバランサー、必要なノード数、アクティブ/アクティブまたはアクティブ/パッシブなどのノードタイプ、およびクラスタリング要件。

ファイル システム要件。たとえば、アプリケーションは生成されたレポートを収集し、アーカイブする前に 1 年間保存する場合があります。この場合、十分なハードドライブ容量が必要です。一部のアプリケーションでは、多次元分析レポート用に他のシステム プロセスまたはデータ ウェアハウス システムで使用するために、データ抽出ファイルとその一時ストレージを生成する必要があります。内部システムまたは外部システムから取得され、アーカイブされる前に 12 ～ 36 か月保存する必要がある、Secure File Transfer Protocol に基づくデータ ファイルもあります。以下の

#12 は、「java.dzone」の「David DeCesare」によるコメント、

#12、「その仕事に最適なツールを使用していない」からのものです。多くの場合、開発者は学習したい言語やツールを運用システムで使用します。通常、これは最良の選択肢ではありません。たとえば、すでに実際にはリレーショナルになっているデータに NoSQL データベースを使用します。どのツールを採用しても、今後 3 年から 5 年 (またはそれ以上) は製品を保守する必要があることに注意してください。

#13. 16 の主要な技術分野における十分な知識の不足。これらの領域には、1) 「同時実行の問題」、2) トランザクションの問題、3) パフォーマンスの問題の特定と修正が含まれます。多くの面接で、私は新しい契約を獲得するためにこれら 3 つの側面の知識を頼りにしました。