c# - 诊断 .NET Legacy

Question

假设您正在接管旧版 .NET 应用程序。用 C# 编写

您将采用哪些前 5 项诊断措施、分析或其他方式来评估应用程序的运行状况？

我不仅关注诊断的“什么”部分，还关注“如何”。例如，确实有必要评估应用程序的快速/最佳响应时间。...但是有没有办法通过代码库的技术诊断来建立/衡量它，而不是仅仅获得用户体验反馈？

_{（来源：gmu.edu）}

是的，肯定会有一些很棒的工具供您使用……如果您也列出它们会很棒。

Answer 1

1. 用户感知

我要做的第一件事就是简单地调查用户。请记住，他们是我们这样做的对象。无论应用程序内部看起来多么可怕，如果用户喜欢它（或者至少不主动不喜欢它），那么您不希望立即开始将其撕开。

我想问一些问题，例如：

• 它运行顺利吗？
• 这个容易用吗？
• 当您使用它时，您是否确信它正在按照您的预期进行操作？
• 是宝马、思域还是平托？

答案将是主观的。没关系。在这一点上，我们只是在寻找广泛的趋势。如果绝大多数用户说它总是崩溃，或者他们害怕执行基本任务，那么你就有麻烦了。

如果该应用程序滋生了迷信，并且您听到诸如“它似乎在星期四早上脱落”或“我不知道此按钮有什​​么作用，但除非我先单击它否则它不起作用”之类的东西，跑到山上.

2. 文档

缺少文档或文档非常过时，是应用程序出现问题的明确迹象。没有文档意味着开发人员偷工减料，或者在不断的死亡行军中过度劳累，以至于他们无法找到时间进行这种“不必要的”工作。

我说的不是用户手册——一个设计良好的应用程序不应该需要它们——我是指技术文档、架构的外观、组件的功能、环境依赖关系、配置设置、需求/用户故事、测试用例/测试计划, 文件格式，你懂的。缺陷跟踪系统也是文档的重要组成部分。

在没有适当文档的情况下，开发人员最终会做出（不正确的）假设。我和业内的几个人谈过，他们认为这是可选的，但我见过或使用过的每个系统都很少或没有文档，最终都充满了错误和设计缺陷。

3. 测试

判断应用程序的健康状况最好的方法就是通过它自己的测试（如果它们可用的话）。单元测试、代码覆盖率、集成测试，甚至手动测试，任何东西都可以在这里工作。测试套件越完整，系统健康的机会就越大。

成功的测试并不能保证太多，除了被测试的特定功能按照编写测试的人所期望的方式工作。但是很多失败的测试，或者多年没有更新的测试，或者根本没有测试——这些都是危险信号。

我不能在这里指出具体的工具，因为每个团队都使用不同的工具进行测试。使用已经在生产中的任何东西。

4. 静态分析

你们中的一些人可能会立即想到“FxCop”。还没有。我要做的第一件事是打破NDepend。

只需快速查看应用程序的依赖关系树，您就会获得大量有关应用程序设计情况的信息。大多数最糟糕的设计反模式——大泥球、循环依赖、意大利面条代码、上帝对象——几乎可以从鸟瞰的依赖关系中立即看到。

接下来，我将运行完整的构建，打开“将警告视为错误”设置。大多数时候通过编译器指令或标志忽略特定警告是可以的，但从字面上忽略警告会带来麻烦。同样，这不能保证一切正常或任何东西都损坏了，但在确定进入实际编码阶段的注意程度时，它是一种非常有用的启发式方法。

在我对整体设计/架构不是完全垃圾感到满意之后，我会看看FxCop。我不认为它的输出是福音，但我对设计警告和使用警告特别感兴趣（安全警告也是一个危险信号，但非常罕见）。

5. 运行时分析

在这一点上，我已经很满意该应用程序，在高层次上，不是一个巨大的垃圾堆。这个阶段在显微镜下的具体应用方面会有很大的不同，但一些好的事情是：

• 记录正常运行下的所有第一次机会异常。这将有助于衡量应用程序的健壮性，查看是否有太多异常被吞下，或者异常是否被用作流量控制。如果您看到很多顶级Exception实例或SystemException衍生品出现，请害怕。

• 通过诸如EQATEC之类的分析器运行它。这应该可以帮助您相当容易地识别任何严重的性能问题。如果应用程序使用 SQL 后端，请使用 SQL 分析工具来观察查询。（确实有单独的步骤来测试数据库的健康状况，这是测试基于数据库的应用程序的关键部分，但我不想离题太远）。

• 观察一些用户——特别注意“仪式”，他们显然无缘无故地做这些事情。这些通常是挥之不去的错误和定时炸弹的标志。还要看看它是否会产生很多错误消息，在“思考”时长时间锁定 UI，等等。基本上，任何你个人讨厌作为用户看到的东西。

• 压力测试。同样，具体工具取决于应用程序，但这尤其适用于基于服务器的应用程序。看看应用程序在重负载下是否仍然可以运行。如果它在断点附近开始超时，那没关系；如果它开始生成奇怪的错误消息或更糟，似乎破坏了数据或状态，那是一个非常糟糕的信号。

---

这就是我现在能想到的。如果有更多的想法，我会更新。

Answer 2

这些不是编码技巧或分析建议，而是评估任何语言程序运行状况的一般方法。按重要性排序

1. 最终用户对此满意吗？
2. 稳定吗？
3. 它健壮吗？
4. 快吗？
5. 内存占用是否长期稳定以及我的预期？

如果所有 5 个问题的答案都是肯定的，那么您的应用程序是健康的。我认为1-3确实是最重要的。它的内部可能并不漂亮，而且可能非常丑陋，但如果它符合这些规范并且应该永远保持在传统模式下（即小错误修复），它是健康的

Answer 3

我建议围绕某些领域编写测试。我不是单元测试的忠实拥护者——尽管我最终写了很多单元测试。我更喜欢测试系统部分的系统测试——所以从域关闭、服务关闭、演示者关闭等不一定是整个系统，而是它的一部分。如果您正在寻找效率，那么这些测试可以围绕代码运行 StopWatch，如果花费的时间太长，则会失败。

另一件好事是通过RedGate 的 ANTs Profiler或Jetbrains 的dotTrace运行标准任务。它会告诉您什么花费了时间以及运行了多少次，这意味着您可以看到可以优化/缓存的位置。

如果您使用的是 NHibernate，那么NHProf非常棒（或者我认为 Ayende 现在已经发布了涵盖更多数据库访问策略的UberProf。）这将警告您正在进行的任何愚蠢的数据库访问。如果仅使用SQL Server 分析器失败，可能会显示您一次又一次地请求相同的数据，但需要更多的努力来过滤掉垃圾。如果您最终使用它，那么您可以将其保存到数据库表中，然后您可以以更智能的方式进行查询。

如果您正在寻找稳健性，那么使用日志记录策略是一件好事 - 捕获所有异常并记录它们。这很容易使用log4net进行设置。如果你达到了你稍微怀疑的某些点，也要记录下来。然后将其运行到一个服务器（我使用易于设置且功能强大的kiwi syslog 服务器），该服务器可以写入数据库，您可以对结果进行分析。我建议不要使用 log4net 的 ADO.NET 附加程序，因为它不是异步的，因此会减慢您的应用程序的速度。

最后取决于应用程序是什么，如果你真的很想花一些时间来测试它的健康状况，你可以使用WaTIN或等效的 Winforms来测试前端。这甚至可能是一个长时间的测试，观察应用程序在使用时的内存/处理器使用情况。如果您不那么担心，那么Windows 性能分析器将允许您在使用应用程序时查看应用程序的各个方面。总是有用的，但你必须真正四处寻找有用的指标。

希望这可以帮助。

Answer 4

我要研究的前两个大项目是：

1. 使用日志记录添加全局异常处理，以及搜索可能“吞下”异常的任何异常处理，隐藏应用程序的问题（我认为还有一个 Windows 性能计数器，它将显示每秒的异常数量）由您的应用程序抛出）。这有助于发现应用程序中任何潜在的数据一致性问题。
2. 添加一些性能监控和日志记录到应用程序可能使用的任何数据持久性和/或外部网络服务依赖项，例如记录数据库查询或需要超过 X 时间才能完成的 Web 服务调用。

Answer 5

如果这与数据库交互，您应该对磁盘 I/O 和磁盘阵列/硬盘驱动器的碎片程度有所了解。对于 MS SQL，分析任何存储过程并查看表上的索引和主键。

您真的不需要为此使用工具，只需要查看计数器和与 DBA 交谈的繁重工作。