レガシ .NET アプリを引き継いでいるとします。C#で書かれた
アプリケーションの正常性を評価するために採用するプロファイリングなどの診断手段の上位 5 つを教えてください。
診断の「WHAT」の部分だけでなく、「HOW」の部分も見ています。たとえば、アプリの高速/最適な応答時間を評価することは確かに必要です。...しかし、ユーザーエクスペリエンスのフィードバックを取得するだけでなく、コードベースの技術的診断によってそれを確立/測定する方法はありますか?
(出典: gmu.edu )
もちろん、その目的のために使用する素晴らしいツールがいくつかあるはずです...それらもリストアップしていただければ幸いです。
私が最初に行うことは、単純にユーザーを調査することです。私たちがこれを行っているのは彼らであることを忘れないでください。アプリケーションの内部がどれほどひどいものであっても、ユーザーがそれを気に入っている (または少なくとも積極的に嫌いではない) 場合は、すぐに引き裂き始めたくありません。
次のような質問をしたいと思います。
答えは主観的なものになります。大丈夫。現時点では、幅広いトレンドを探しているだけです。圧倒的な数のユーザーが、常にクラッシュする、または基本的なタスクを実行するのが怖いと言っている場合、問題が発生しています。
アプリが迷信を助長し、「木曜日の朝になると消えてしまうようだ」「このボタンが何をするかわからないが、最初にクリックしないと機能しない」などの言葉が聞こえたら、丘に向かって走ってください.
ドキュメントが不足していたり、ドキュメントがひどく古くなっている場合は、アプリケーションが適切でないことを示しています。ドキュメントがないということは、開発スタッフが手抜きをしたり、絶え間ない死の行進で働きすぎて、この種の「不必要な」作業の時間を見つけることができないことを意味します.
私はユーザー マニュアルについて話しているのではありません - 適切に設計されたアプリには必要ありません - 技術文書、アーキテクチャの外観、コンポーネントの機能、環境の依存関係、構成設定、要件/ユーザー ストーリー、テスト ケース/テスト計画を意味します、ファイル形式、あなたはアイデアを得る. 欠陥追跡システムも文書化の重要な部分です。
開発者は、適切なドキュメントがない場合、(誤った) 仮定を行うことになります。これはオプションだと考えている業界の何人かの人々と話をしましたが、私がこれまでに見たり作業したりしたすべてのシステムは、ドキュメントがほとんどまたはまったくなく、バグや設計上の欠陥でいっぱいになりました.
アプリケーションの正常性を判断するには、独自のテストが利用できる場合に勝るものはありません。単体テスト、コード カバレッジ、統合テスト、さらには手動テストなど、ここでは何でも機能します。一連のテストが完成すればするほど、システムが正常である可能性が高くなります。
テストが成功しても、テスト対象の特定の機能が、テストを書いた人々が期待するように動作することを除いて、多くの保証はありません。しかし、多くの失敗したテスト、または何年も更新されていないテスト、またはテストがまったくない場合、これらは危険信号です。
すべてのチームがテストに異なるツールを使用しているため、ここで特定のツールを示すことはできません。すでに生産されているものは何でも使用できます。
すぐに「FxCop」と思った人もいるでしょう。まだ。私が最初にすることは、NDependを分解することです。
アプリケーションの依存関係ツリーをざっと見るだけで、アプリケーションの設計がいかに優れているかに関する膨大な量の情報が得られます。Big Ball of Mud、Circular Dependencies、Spaghetti Code、God Objectsなどの最悪の設計アンチパターンのほとんどは、依存関係を俯瞰するだけですぐにわかります。
次に、「警告をエラーとして扱う」設定をオンにして、フル ビルドを実行します。ほとんどの場合、コンパイラ ディレクティブまたはフラグを介して特定の警告を無視しても問題ありませんが、文字通り警告を無視すると問題が発生します。繰り返しますが、これはすべてが正常であること、または何かが壊れていることを保証するものではありませんが、実際のコーディングフェーズに入った注意のレベルを決定する上で非常に役立つヒューリスティックです。
全体的な設計/アーキテクチャが完全なゴミではないことに満足したら、 FxCopを調べます。私はその出力を福音とは見なしませんが、特に設計警告と使用警告に関心があります (セキュリティ警告も危険信号ですが、非常にまれです)。
この時点で、私は、このアプリケーションが大まかに言うと、大したことではないことにすでに満足しています。このフェーズは、顕微鏡下での特定のアプリケーションに関してかなり異なりますが、行うべきいくつかの良いことは次のとおりです。
通常の実行で最初の例外をすべてログに記録します。これは、アプリケーションの堅牢性を評価し、飲み込まれている例外が多すぎるかどうか、または例外がフロー制御として使用されているかどうかを確認するのに役立ちます。トップレベルのExceptionインスタンスまたはSystemException派生物が多数表示されている場合は、恐れてください。
EQATECなどのプロファイラーで実行します。これにより、重大なパフォーマンスの問題を簡単に特定できます。アプリケーションが SQL バックエンドを使用している場合は、SQL プロファイリング ツールを使用してクエリを監視します。（実際には、データベースの健全性をテストするための個別の手順があります。これは、データベースに基づくアプリケーションをテストする際の重要な部分ですが、トピックから外れすぎたくありません）。
何人かのユーザーに注目してください - 特に「儀式」、つまり明らかに理由もなく彼らが行っていることを探してください。これらは通常、長引くバグや時限爆弾の兆候です。また、大量のエラー メッセージが生成されるかどうか、「考えている」間 UI が長時間ロックされるかどうかなども確認してください。基本的に、ユーザーとして個人的に見たくないものは何でも。
ストレステスト。繰り返しになりますが、特定のツールはアプリケーションによって異なりますが、これは特にサーバー ベースのアプリに当てはまります。アプリケーションが高負荷下でも機能するかどうかを確認します。ブレークポイント近くでタイムアウトし始めても問題ありません。奇妙なエラー メッセージが表示されたり、データや状態が破損しているように見える場合は、非常に悪い兆候です。
そして、それは今のところ私が考えることができるすべてです。また思いついたら更新します。
特定の領域の周りにテストを書くことをお勧めします。私はユニットテストの大ファンではありません-私はそれらのかなりの数を書くことになりますが。私は、システムの一部をテストするシステムテストを好みます。つまり、ドメインダウン、サービスダウン、プレゼンターダウンなど、必ずしもシステム全体ではなく、システムの一部をテストします。効率を求めている場合、これらのテストはコードの周りでStopWatchを実行し、時間がかかりすぎると失敗する可能性があります。
もう1つの優れた方法は、RedGateのANTsProfilerまたはJetbrainsのdotTraceを介して標準タスクを実行することです。何に時間がかかり、何回実行されたかがわかります。つまり、最適化/キャッシュできる場所を確認できます。
NHibernateを使用している場合、NHProfは優れています（または、Ayendeがより多くのDBアクセス戦略をカバーするUberProfをリリースしたと思います）。これにより、愚かなDBアクセスが行われていることを警告します。SQL Serverプロファイラーを使用してこれに失敗すると、同じデータを何度も要求しているように見える場合がありますが、ゴミを取り除くためにより多くの労力が必要になります。それを使用することになった場合は、それをDBテーブルに保存して、よりインテリジェントな方法でクエリを実行できます。
堅牢性を求めている場合は、ログ戦略を使用することをお勧めします。すべての例外をキャッチしてログに記録します。これは、 log4netを使用して設定するのに十分簡単です。また、少し疑わしい特定のポイントに到達した場合もログに記録します。次に、これをサーバー（セットアップが簡単で非常に強力なkiwi syslogサーバーを使用）に実行して、DBに書き込み、結果の分析を実行できるようにします。log4netのADO.NETアペンダーは非同期ではないため、アプリの速度が低下するため、お勧めしません。
最後に、アプリが何であるかに応じて、そのヘルスのテストに本当に時間を費やすことに本当に熱心である場合は、フロントエンドのテストに相当するWaTINまたはWinformsを使用できます。これは、アプリケーションが使用されている間、アプリケーションのメモリ/プロセッサの使用状況を監視する長時間のテストである可能性もあります。それほど心配していない場合は、Windowsパフォーマンスアナライザーを使用すると、アプリケーションのさまざまな側面を使用しながら確認できます。常に便利ですが、便利な指標を取得するには、実際に調べてみる必要があります。
お役に立てれば。
これらはコーディングのヒントやプロファイリングのアドバイスではなく、任意の言語でプログラムの状態を評価する一般的な方法です。重要度順に
これら 5 つの質問すべてに対する答えが「はい」の場合、アプリケーションは健全です。1～3が最も重要だと思います。内部はきれいではないかもしれませんし、おそらく右下が醜いかもしれませんが、これらの仕様を満たしており、レガシーモードを永久に維持する必要がある場合は健全です（つまり、小さなバグ修正）
これがデータベースとやり取りする場合は、ディスク I/O とディスク アレイ/ハード ドライブの断片化の程度を把握する必要があります。MS SQL の場合、ストアド プロシージャを分析し、テーブルのインデックスと主キーを確認します。
このためのツールは本当に必要ありません。カウンタを確認して DBA と話すという単調な作業だけです。
私が検討する最初の2つの大きな項目は次のとおりです。
