我们如何识别软件缺陷

2009年8月18日 · Max Kanat-Alexander

在上篇文章后，有人提问：“你们究竟如何识别软件中的缺陷？”

有些问题显而易见：点击按钮后程序需要10分钟响应——这显然糟糕；某个页面每周收到100条UI投诉——同样明显存在问题。通常存在一两个特别突出的严重缺陷，这些就是需要优先解决的焦点，即便解决它们需要巨大工作量。

以Bugzilla 3.0之前的版本为例：每次加载页面时都需要重新编译所有库和完整脚本，导致慢速机器上页面加载延迟数秒，快速机器也至少延迟1秒。性能问题是首要明显缺陷，但更严重的是代码质量问题——由于企业频繁定制需求，代码已变成难以理解的混乱状态。

这两个问题的解决方案殊途同归：通过允许预编译脚本（在Web服务器启动时完成而非每次页面加载时），同时配合大规模代码重构，我们既解决了性能问题也改善了代码质量。不过这个过程经历了四个主要版本（2.18、2.20、2.22到3.0）才最终完成，每个版本都在持续改进。

当核心问题解决后，次优先级问题就浮出水面。此时我们通过两项关键措施建立优先级：

值得注意的是，调研时机至关重要。如果在早期核心问题未解决时就开展调研，结果只会验证已知问题或列出当时无力解决的清单。只有当团队开始思考"现阶段什么最重要"时，数据收集才真正产生价值。

总结改善路径：首先解决最显著的少数核心问题，随后通过用户反馈确定后续优化方向。这种阶段性推进策略，配合严谨的数据收集，最终使Bugzilla实现了质的飞跃。

读者评论精选

Ben 2009年8月22日
Windows系统逐渐移除可定制化功能的现象值得警惕。早期版本允许通过启动项和系统工具深度优化，而新版剥夺了这些技术性控制权，这种设计倒退令人费解。

Max回复
这本质是复杂度管理失衡的典型案例。系统底层复杂度未减，却移除了帮助用户应对复杂度的工具链，最终损害了用户体验。

Ape 2010年6月12日
推荐参考《为什么软件糟糕》演讲，其中系统分析了"缺陷"的本质定义。