.NETレガシーの診断

Question

レガシー.NETアプリを引き継いでいると仮定します。 C＃で書かれています

アプリケーションの健康を評価するために採用するトップ5の診断測定、プロファイリング、またはその他は何ですか？

私は診断の「何の」部分だけでなく、「方法」を見ています。たとえば、アプリの高速/最適応答時間を評価する必要があります。 ...しかし、ユーザーエクスペリエンスのフィードバックを取得するのではなく、コードベースの技術的診断によってそれを確立/測定する方法はありますか？

_{（ソース： gmu.edu)}

そして、はい、いくつかの拘束力があります 驚くばかり 目的のために使用するツール...あなたもそれらをリストすると素晴らしいでしょう。

Answer 1

1.ユーザー認識

非常に 私が最初にすることは、単にユーザーを調査することです。覚えておいてください、彼らは私たちがこれをしているものです。どんなに恐ろしいアプリケーションが中にあるかもしれませんが、ユーザーがそれを愛している場合（または少なくとも積極的に嫌いではない場合）、すぐに引き裂き始めたくありません。

次のような質問をしたい：

• スムーズに実行されますか？
• 使いやすいですか？
• あなたがそれを使用するとき、あなたは感じますか？ 自信 それがあなたが期待していることをしていること？
• それはBMW、シビック、またはピントですか？

答えは主観的です。大丈夫。この時点で、私たちは幅広いトレンドを探しています。圧倒的な数のユーザーが、常にクラッシュしていると言ったり、基本的なタスクを実行することを恐れていると言っている場合、問題が発生しています。

アプリが繁殖する場合 迷信, 、そして、「木曜日の朝に剥がれそうです」や「このボタンが何をするのかわかりませんが、最初にクリックしない限り機能しない」などのことが聞こえます。

2.ドキュメント

ドキュメントの不足、または恐ろしく時代遅れのドキュメントは、病気のアプリケーションの確かな兆候です。開発スタッフがコーナーを切ったか、絶え間ない死の行進であまりにも勤勉であるため、この種の「不必要な」仕事の時間を見つけることができないという文書はありません。

私はユーザーマニュアルについて話していません - 適切に設計されたアプリはそれらを必要としません - 私は技術文書、アーキテクチャの外観、コンポーネントの行為、環境依存関係、構成設定、要件/ユーザーストーリー、テストケース/テストプランを意味します、ファイル形式、アイデアが得られます。欠陥追跡システムもドキュメントの重要な部分です。

開発者は、適切なドキュメントがない場合に（誤った）仮定を行うことになります。私はこれがオプションであると考えている業界の何人かの人々と話をしましたが、ドキュメントがほとんどまたはまったくなかったすべてのシステムは、バグやデザインの欠陥に悩まされていませんでした。

3.テスト

アプリケーションの健康を判断するためのより良い方法はありません。ユニットテスト、コードカバレッジ、統合テスト、さらには手動テスト、さらにはここで機能します。一連のテストスイートがより完全になればなるほど、システムが健康になる可能性が高くなります。

成功したテストはそうではありません 保証 それ以外は、テストされている特定の機能が、テストを書いた人々が期待するように機能します。しかし、多くの失敗したテスト、または何年も更新されていない、またはまったくテストがないテスト - それらは赤い旗です。

すべてのチームがテストに異なるツールを使用しているため、ここで特定のツールを指すことはできません。すでに生産されているものは何でも作業します。

4.静的分析

あなたの何人かはおそらくすぐに「fxcop」と思ったでしょう。まだ。私が最初にすることは壊れることです ndepend.

アプリケーションの依存関係ツリーを簡単に見ると 甚大 アプリケーションがどの程度設計されているかに関する情報の量。最悪のデザインアンチパターンのほとんど - 泥の大きなボール, 円形依存関係, スパゲッティコード, 神は目的です - ほぼ表示されます すぐに 依存関係の鳥瞰図から。

次に、完全なビルドを実行し、「エラーとして警告を扱う」設定をオンにします。コンパイラディレクティブまたはフラグを介して特定の警告を無視することはほとんどの場合大丈夫ですが、 文字通り 警告を無視すると、トラブルが綴られます。繰り返しますが、これはすべてが大丈夫であるか、何かが壊れていることを保証するものではありませんが、実際のケアのレベルを決定する上で非常に有用なヒューリスティックです コーディング 段階。

後 私は、全体的なデザイン/アーキテクチャが完全なゴミではないことに満足しています、 それから 私は見ます fxcop. 。私はその出力を福音として取っていませんが、私は特に興味があります 設計警告 と 使用警告 （セキュリティ警告も赤い旗ですが、非常にまれです）。

5.ランタイム分析

この時点で、私はすでに、高レベルでのアプリケーションが吸う巨大なマウンドではないことに満足しています。このフェーズは、顕微鏡下の特定のアプリケーションに関してかなり異なりますが、いくつかの良いことは次のとおりです。

• 通常の実行の下で、すべてのファーストチャンスの例外を記録します。これにより、アプリケーションの堅牢性を測定し、多すぎる例外が飲み込まれているかどうか、または例外がフロー制御として使用されているかどうかを確認するのに役立ちます。トップレベルがたくさん見られる場合 Exception インスタンスまたは SystemException デリバティブが現れ、恐れてください。

• 次のようなプロファイラーを介して実行します eqatec. 。これは、深刻なパフォーマンスの問題をかなり簡単に識別するのに役立つはずです。アプリケーションがSQLバックエンドを使用している場合、SQLプロファイリングツールを使用してクエリを視聴します。 （実際には、データベースの健康をテストするための手順が分かれています。これは、アプリケーションに基づいたアプリケーションのテストの重要な部分ですが、あまりにもトピックになりすぎたくありません）。

• 数人のユーザーを見てください - 特に「儀式」を探してください。これらは通常、長引くバグとカチカチな時間爆弾の兆候です。また、多くのエラーメッセージを生成し、「考えている」間、UIを長期間ロックしているかどうかなどを確認します。基本的に、あなたが個人的にユーザーとして見るのが嫌いなものは何でも。

• ストレステスト。繰り返しますが、特定のツールはアプリケーションに依存しますが、これは特にサーバーベースのアプリに適用できます。アプリケーションが重い負荷の下で機能することができるかどうかを確認します。ブレークポイントの近くでタイミングを出し始めた場合、それは大丈夫です。それが奇妙なエラーメッセージの生成を開始するか、さらに悪いことに、データや状態を破壊しているように見える場合、それは 非常に 悪い兆候。

---

そして、それは今のところ私が考えることができるすべてについてです。これ以上思い浮かぶなら、更新します。

Answer 2

これらはコーディングのヒントやプロファイリングアドバイスではなく、あらゆる言語でプログラムの健康を評価する一般的な方法です。重要性の順に

1. エンドユーザーはそれに満足していますか？
2. 安定していますか？
3. 堅牢ですか？
4. 速いですか？
5. メモリフットプリントは長期にわたって安定していますか？

これらの質問のすべてに対する答えがイエスである場合、あなたは健全なアプリケーションを持っています。私は1-3が本当に最も重要だと主張します。内側にはきれいではなく、おそらく右下にあるかもしれませんが、それらの仕様を満たし、永遠にレガシーモードにとどまる必要がある場合は健康です（つまり、小さなバグフィックス）

Answer 3

書くことをお勧めします テスト 特定のエリア周辺。私はユニットテストの大ファンではありません - 私はそれらのかなりの数を書くことになりますが。システムの一部をテストするシステムテストを好む - ドメインダウン、サービスダウン、プレゼンターダウンなどから、システム全体ではなく、その一部ではなく。効率を探している場合、これらのテストはコードの周りにストップウォッチを実行し、時間がかかりすぎると失敗する可能性があります。

もう1つの良いことは、標準タスクを実行することです アリのプロファイラー Redgateからまたは ドットレース ジェットブレインから。何が時間がかかり、何回実行されているのかがわかります。つまり、どこで最適化/キャッシュできるかがわかります。

nhibernateを使用している場合は nhprof 素晴らしいです（または、Ayendeが今リリースしたと思います uberprof これは、より多くのDBアクセス戦略をカバーしています。）これにより、愚かなDBアクセスが進行中であることが警告されます。これを使用してこれに失敗します SQL Server Profiler 同じデータを何度も何度もリクエストすることを示すかもしれませんが、ゴミをフィルタリングするより多くの労力が必要です。それを使用することになった場合、それをDBテーブルに保存することができます。これにより、よりインテリジェントな方法でクエリができます。

堅牢性を探している場合、使用するのに適したことはロギング戦略です。すべての例外をキャッチしてログに記録します。これは、使用してセットアップするのに十分簡単です log4net. 。また、あなたが少し疑っている特定のポイントを押した場合にも記録します。次に、これをサーバーに走らせます（私は使用します Kiwi Syslogサーバー セットアップが簡単で非常に強力です）DBに書き込むことができ、結果について分析を実行できます。 log4netのado.net appenderに反対することをお勧めします。それは非同期ではないため、アプリを遅くすることができます。

最後に、アプリが何であるかに依存しています。あなたがその健康のテストに時間を費やすことに本当に熱心である場合、あなたが使用できる ワティン または WinForms同等 フロントエンドをテストします。これは、使用中にアプリケーションのメモリ/プロセッサの使用を視聴する長期テストでさえあります。あなたがそんなに心配していないなら、 Windowsパフォーマンスアナライザー 使用中にアプリケーションのさまざまな側面を見ることができます。常に便利ですが、便利なメトリックを取得するために本当にうんざりする必要があります。

お役に立てれば。

Answer 4

私が検討する最初の2つの大きなアイテムは次のとおりです。

1. ロギングを使用したグローバルな例外処理を追加し、例外を「飲み込む」可能性のある例外処理を検索し、アプリケーションに問題を隠します（秒ごとに例外の数を公開するWindowsパフォーマンスカウンターもあると思います。アプリケーションによって投げられます）。これは、アプリケーションの潜在的なデータの一貫性の問題を明らかにするのに役立ちます。
2. データベースのクエリのロギングや、完了するまでにx時間より長くかかるWebサービスコールなど、アプリケーションが使用している可能性のあるデータの永続性および/または外部ネットワークサービス依存関係にパフォーマンス監視とロギングを追加します。

Answer 5

これがデータベースと対話する場合、ディスクI / Oの感触とディスクアレイ /ハードドライブの断片化の程度を取得する必要があります。 MS SQLの場合、ストアドプロシージャを分析し、テーブル上のインデックスとプライマリキーを確認します。

あなたは本当にこのためのツールを必要としません、カウンターをレビューしてDBAと話すといううなりの仕事だけです。