我们如何识别软件缺陷

2009 年 8 月 18 日 | Max Kanat-Alexander

在我上一篇文章发布后，有人提问："那么，你们究竟如何判断哪些部分需要改进？"

有些问题确实显而易见。比如点击按钮后程序需要 10 分钟才有响应——这显然很糟糕。某个页面每周收到 100 条 UI 投诉——这也明显存在问题。

通常存在一两个特别突出的严重问题，它们应该被优先解决，即便需要大量工作。例如在 Bugzilla 3.0 之前，每次加载页面时都需要重新编译所有库和整个脚本，这在慢速机器上会导致数秒延迟，快速机器也至少需要 1 秒。因此性能是 Bugzilla 最明显的问题之一。但更重要的是代码质量本身——由于企业经常需要定制 Bugzilla，那些晦涩难懂的代码给所有人带来了困扰。

幸运的是，这两个问题可以通过同一个方案解决。我们允许用户在 web 服务器启动时预编译所有脚本，而不是每次加载页面都编译。为实现预编译，我们进行了大规模代码重构，最终通过改善代码结构解决了性能问题。

不过这个过程经历了四个主要版本（2.18、2.20、2.22 和 3.0）才完成！每个版本都修复了大量小问题，使得新版总比旧版更好。但解决主要问题需要巨大投入——绝非一夜之间就能完成。

有时大型软件问题之所以未被解决，正是因为修复工作需要巨大投入。但这不意味着可以忽视它们，而是需要制定长期计划，并确保期间能持续发布新版本。

当主要问题解决后，我们突然发现还有一大堆其他问题需要处理！原先被主要问题掩盖的"明显"缺陷现在都浮现出来。理论上我们可以这样无限循环下去，但很快就面临新挑战：当同时出现 50 个"明显"问题时，如何确定修复优先级？

在 Bugzilla 项目中，两项工作极大帮助我们确定了优先级：用户调查和可用性研究。调查中最关键的是允许用户以自由文本形式回答问题。我直接向管理员发送个性化问卷，没有选择题，只有开放式问题。令人惊讶的是，他们非常乐意回复，许多人还专门致谢。

可用性研究中最有价值的是专家直接指出违反可用性原则的设计。新鲜视角（专家从未接触过 Bugzilla）尤为重要，他们不会认为"本来就是这样"。

这些数据帮助我们有效确定了优先级。但必须注意的是，如果在解决主要问题前就开展调研，结果可能会让我们不知所措——要么重复已知问题，要么发现大量当时无力解决的问题。只有当团队开始思考"现在什么最重要"时，数据收集才变得极具价值。

总结来说，当需要改进软件时：首先解决已知的最突出几个问题，不计代价；之后会浮现大量待解决问题，这时再收集用户数据，优先解决他们反馈最强烈的问题。

-Max

读者评论

Ben 2009 年 8 月 22 日

除了明显问题外，程序（特别是 Windows）经常移除用户过去可用的技术功能也很糟糕。Windows 曾经允许通过启动选项和系统工具进行各种个性化设置来优化程序运行，但新版移除了大部分用户可操控的功能。

Max 回复

我认为微软试图解决 Windows 过于复杂的问题，但采取了错误方式。那些技术功能本是为应对系统复杂性而设，现在只移除功能却不解决根本复杂性反而帮倒忙。

Ape 2010 年 6 月 12 日

推荐观看《为什么软件很糟糕》演讲，它真正探讨了"糟糕"的定义。

Max 回复

这个演讲确实很有启发性。更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）公众号二维码

办公AI智能小助手