假设您要接管旧版 .NET 应用程序。用 C# 编写
您将用于评估应用程序运行状况的前 5 项诊断措施、分析或其他方式是什么？
我不仅关注诊断的“什么”部分，还关注“如何”。例如确实有必要评估应用程序的快速/最佳响应时间。 ...但是有没有办法通过代码库的技术诊断来建立/衡量它，而不是仅仅获得用户体验反馈？
（来源：gmu.edu）
是的，肯定会有一些很棒的工具供您使用……如果您也列出它们，那就太好了。
【问题讨论】：
标签： c# .net profiling diagnostics legacy-app
非常我要做的第一件事就是简单地调查用户。请记住，他们是我们这样做的对象。无论应用程序内部看起来多么糟糕，如果用户喜欢它（或者至少不主动不喜欢它），那么您就不想立即开始将其拆开。
我想问以下问题：
答案将是主观的。没关系。在这一点上，我们只是在寻找广泛的趋势。如果绝大多数用户说它总是崩溃，或者他们害怕执行基本任务，那么你就有麻烦了。
如果应用程序滋生迷信，并且您听到诸如“它似乎在星期四早上脱落”或“我不知道这个按钮有什么作用，但它不起作用，除非我先点击它”，奔向山丘。
缺少文档或文档严重过时，是应用程序出现问题的明确迹象。没有文档意味着开发人员偷工减料，或者在不断的死亡行军中过度劳累，以至于他们无法找到时间进行这种“不必要的”工作。
我说的不是用户手册——一个设计良好的应用程序不应该需要它们——我指的是技术文档、架构的外观、组件的作用、环境依赖关系、配置设置、需求/用户故事、测试用例/test 计划，文件格式，你懂的。缺陷跟踪系统也是文档的重要组成部分。
在没有适当文档的情况下，开发人员最终会做出（不正确的）假设。我与业内的一些人交谈过，他们认为这是可选的，但我所见过或使用过的每一个几乎没有文档或没有文档的系统最终都充满了错误和设计缺陷。
判断应用程序运行状况的最佳方法是通过其自身的测试（如果可用）。单元测试、代码覆盖率、集成测试，甚至手动测试，任何东西都可以在这里工作。测试套件越完整，系统健康的机会就越大。
成功的测试根本不能保证，除了被测试的特定功能按照编写测试的人所期望的方式工作之外。但是很多失败的测试，或者多年没有更新的测试，或者根本没有测试——这些都是危险信号。
我不能在这里指出具体的工具，因为每个团队都使用不同的工具进行测试。使用任何已经在生产中的东西。
你们中的一些人可能会立即想到“FxCop”。还没有。我要做的第一件事就是突破NDepend。
只要快速浏览一下应用程序的依赖关系树，您就会大量了解应用程序的设计情况。大多数最糟糕的设计反模式 - Big Ball of Mud、Circular Dependencies、Spaghetti Code、God Objects - 几乎立即从依赖项的鸟瞰图可见。
接下来，我将运行完整的构建，打开“将警告视为错误”设置。大多数时候通过编译器指令或标志忽略特定警告是可以的，但字面上忽略警告会带来麻烦。同样，这并不能保证一切正常或任何东西都损坏了，但它是确定进入实际编码阶段的注意程度的非常有用的启发式方法。
之后我对整体设计/架构不是完全垃圾感到满意，然后我会看看FxCop。我不认为它的输出是福音，但我对Design Warnings 和Usage Warnings 特别感兴趣（安全警告也是一个危险信号，但非常罕见）。
在这一点上，我已经很满意该应用程序，在高层次上，不是一个巨大的垃圾堆。这个阶段在显微镜下的具体应用会有很大的不同，但一些好的事情是：
在正常运行下记录所有第一次机会异常。这将有助于衡量应用程序的健壮性，查看是否有太多异常被吞下，或者异常是否被用作流量控制。如果您看到很多顶级的Exception 实例或SystemException 派生类出现，请害怕。
通过诸如EQATEC 之类的分析器运行它。这应该可以帮助您相当容易地识别任何严重的性能问题。如果应用程序使用 SQL 后端，请使用 SQL 分析工具来观察查询。 （确实有单独的步骤来测试数据库的健康状况，这是测试基于数据库的应用程序的关键部分，但我不想离题太远）。
观察一些用户 - 特别注意“仪式”，他们显然无缘无故地做这些事情。这些通常是挥之不去的错误和定时炸弹的标志。还要看看它是否会产生很多错误消息，在“思考”时长时间锁定 UI，等等。基本上，任何你个人讨厌作为用户看到的东西。
压力测试。同样，具体工具取决于应用程序，但这尤其适用于基于服务器的应用程序。看看应用程序在重负载下是否仍然可以运行。如果它在断点附近开始超时，那没关系；如果它开始生成奇怪的错误消息或更糟，似乎损坏了数据或状态，那是一个非常不好的迹象。
这就是我现在能想到的。如果有更多的想法，我会更新。
【讨论】：
这些不是编码技巧或分析建议，而是评估任何语言程序运行状况的一般方法。按重要性排序
如果所有 5 个问题的答案都是“是”，那么您的应用程序运行良好。我认为1-3确实是最重要的。它的内部可能并不漂亮，而且可能非常丑陋，但如果它符合这些规范并且应该永远保持传统模式（即小错误修复），它是健康的
【讨论】：
我建议围绕某些领域编写测试。我不是单元测试的忠实拥护者——尽管我最终写了很多单元测试。我更喜欢测试系统部分的系统测试——所以从域停机、服务停机、演示者停机等不一定是整个系统，而是它的一部分。如果您正在寻找效率，那么这些测试可以围绕代码运行 StopWatch，如果花费的时间过长，则会失败。
另一件好事是通过 RedGate 的 ANTs Profiler 或 Jetbrains 的 dotTrace 运行标准任务。它会告诉您什么花费了时间以及运行了多少次，这意味着您可以看到可以优化/缓存的位置。
如果您使用 NHibernate，那么 NHProf 非常好（或者我认为 Ayende 现在已经发布了涵盖更多数据库访问策略的 UberProf。）这会警告您任何愚蠢的数据库访问正在进行。如果仅使用 SQL Server 分析器 失败，可能会显示您一次又一次地请求相同的数据，但需要更多的努力来过滤掉垃圾。如果您最终使用了它，那么您可以将其保存到数据库表中，然后您可以以更智能的方式进行查询。
如果您正在寻找稳健性，那么使用日志记录策略是一件好事 - 捕获所有异常并记录它们。这很容易使用 log4net 进行设置。如果你达到了你稍微怀疑的某些点，也要记录下来。然后将它运行到可以写入数据库的服务器（我使用 kiwi syslog 服务器，它易于设置且功能强大），您可以对结果进行分析。我建议不要使用 log4net 的 ADO.NET 附加程序，因为它不是异步的，因此会减慢您的应用程序的速度。
最后取决于应用程序是什么，如果你真的很想花一些时间来测试它的健康状况，你可以使用 WaTIN 或 Winforms 等效 来测试前端。这甚至可能是一个长时间的测试，观察应用程序在使用时的内存/处理器使用情况。如果您不那么担心，那么 windows 性能分析器 将允许您在使用应用程序时查看应用程序的各个方面。总是有用的，但你必须真正四处寻找有用的指标。
希望这会有所帮助。
【讨论】：
我要研究的前两个大项目是：
【讨论】：
如果这与数据库交互，您应该对磁盘 I/O 和磁盘阵列/硬盘驱动器的碎片程度有所了解。对于 MS SQL，分析任何存储过程并查看表上的索引和主键。
你真的不需要工具来做这件事，只需要检查计数器和与 DBA 交谈的繁重工作。
【讨论】：