诊断.NET遗留问题

1。用户感知

这个 非常 我要做的第一件事就是简单地调查用户。记住,他们是我们做这件事的人。不管应用程序看起来有多糟糕,如果用户喜欢它(或者至少不主动讨厌它),那么你就不想立即开始拆开它。

我想问一些问题,比如:

• 运行平稳吗?
• 使用方便吗?
• 当你使用它的时候,你觉得 自信的 它在做你想做的事?
• 是宝马、思域还是平托?

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

如果应用程序繁殖 迷信 ,然后你会听到这样的话:“它似乎在星期四早上脱落了”或“我不知道这个按钮是做什么的,但它不起作用,除非我先点击它”,向山跑。

2。文档

缺少文档,或者文档已经严重过时,这无疑是一个病态申请的迹象。没有文档意味着开发人员偷工减料,或者在不断的死亡行军中工作过度,以至于他们找不到时间进行这种“不必要”的工作。

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

开发人员最终在缺乏适当文档的情况下做出(不正确的)假设。我已经和一些业内人士谈过,他们认为这是可选的,但我所见过或工作过的每一个系统都很少或根本没有文档,最终都被错误和设计缺陷所困扰。

三。测验

没有比通过自己的测试(如果有的话)更好的方法来判断应用程序的健康状况。单元测试、代码覆盖率、集成测试,甚至手动测试,任何东西都可以在这里工作。测试套件越完整,系统健康的可能性就越大。

成功的测试不会 保证 除此之外,被测试的特定特性的工作方式与编写测试的人所期望的完全相同。但是很多失败的测试,或者多年没有更新的测试,或者根本没有测试——这些都是危险信号。

我不能在这里指出特定的工具,因为每个团队使用不同的工具进行测试。与已经在生产中的产品一起工作。

4。静态分析

你们中的一些人可能会立刻想到“fxcop”。还没有。我要做的第一件事就是 NDepend .

只需快速查看应用程序的依赖关系树即可 巨大的 有关应用程序设计得如何的大量信息。大多数最糟糕的反模式设计 Big Ball of Mud , Circular Dependencies , Spaghetti Code , God Objects -几乎可以看到 立即 仅仅从鸟瞰的角度来看依赖关系。

接下来,我将运行一个完整的构建,打开“将警告视为错误”设置。通过编译器指令或标志忽略特定警告在大多数情况下都是正确的,但是 字面 忽视警告意味着麻烦。同样,这也不能保证你一切都好或者任何东西都坏了,但是这是一个非常有用的启发式方法,可以用来确定实际的护理水平 编码 相位。

后 我很满意总体设计/架构不是完全的垃圾, 然后 我会看看 FxCop . 我不认为它的输出是福音,但我特别感兴趣的是 Design Warnings 和 Usage Warnings (安全警告也是一个危险信号,但非常罕见)。

5。运行时分析

在这一点上,我已经很满意,在高水平上,这个应用程序并不是一个巨大的垃圾堆。这个阶段对于显微镜下的具体应用会有很大的不同,但是有一些好的事情要做:

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

• 通过剖析器运行它,比如 EQATEC . 这将帮助您相当容易地识别出任何严重的性能问题。如果应用程序使用SQL后端,请使用SQL分析工具监视查询。(实际上,测试数据库的运行状况有不同的步骤,这是测试基于数据库的应用程序的关键部分,但我不想太过回避这个话题)。

• 看一些用户-特别是“仪式”,他们做的事情显然没有理由。这些通常是挥之不去的虫子和定时炸弹的信号。还要查看它是否生成了大量错误消息,在“思考”时长时间锁定ui,等等。基本上,任何你个人不愿看到的用户。

• 压力测试。同样,特定工具依赖于应用程序,但这尤其适用于基于服务器的应用程序。查看应用程序是否仍能在重载下运行。如果它在临界点附近开始计时,那没关系;如果它开始生成奇怪的错误消息,或者更糟,似乎损坏了数据或状态,那是 非常 坏征兆。

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

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

1. 最终用户对此满意吗?
2. 它稳定吗?
3. 它结实吗?
4. 速度快吗?
5. 内存占用在很长一段时间内是稳定的吗?我的期望是什么?

如果这5个问题的答案都是肯定的,那么你的申请是健康的。我认为1-3真的是最重要的。它的内部可能不好看,也可能很难看,但是如果它满足这些规范,并且应该永远保持在遗留模式(即小错误修复),那么它是健康的。

我建议你写 测验 在某些地区。我不太喜欢单元测试——尽管我最后写了很多单元测试。我更喜欢测试系统部分的系统测试——因此从域关闭、服务关闭、演示者关闭等不一定是整个系统,而是它的一部分。如果您在寻找效率,那么这些测试可以在代码周围运行秒表,如果花费太长时间,则会失败。

另一个好方法是运行标准任务 蚂蚁剖面仪 从红门或 遗迹 从喷气式飞机上。它会告诉你花费了多少时间和运行了多少次,这意味着你可以看到哪里可以优化/缓存。

如果你用的是NHibernate 小精灵 很好(或者我认为艾恩德现在已经发布了 乌伯罗夫 这将警告你任何愚蠢的数据库访问正在进行。失败了就用 SQL Server探查器 可能会显示您一次又一次地请求相同的数据,但将需要更大的努力过滤掉垃圾。如果您最终使用了它,那么您可以将它保存到一个db表中,然后可以用更智能的方式进行查询。

如果您在寻找健壮性,那么最好使用日志记录策略—捕获所有异常并记录它们。这很容易设置使用 Log4NET . 如果你碰到了你有点怀疑的地方,也要记录下来。然后把它运行到服务器上(我使用 Kiwi系统日志服务器 这是很容易设置和相当强大),可以写入数据库,你可以运行结果分析。我建议不要使用ADO.NET Appender for Log4net,因为它不是异步的,因此会降低应用程序的速度。

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

希望这有帮助。

我要调查的前两大项目是:

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

如果这与数据库交互,您应该能感觉到磁盘I/O和磁盘阵列/硬盘驱动器的碎片程度。对于ms-sql,分析任何存储过程并检查表上的索引和主键。

你真的不需要这些工具,只需要查看计数器和与dba交谈的繁琐工作。