那不是Bug，是新需求

原文作者：Jeff Atwood

自从我干上软件开发这一行。而且使用了Bug跟踪系统。我们在每个项目里都会纠结一个主要的问题：你怎么能把Bug与功能需求区分开来？

当然，假设程序崩溃了，这毫无疑问是Bug。

只是，那或许仅仅占你每天所处理问题的10%。

为了避免项目的彻底失败。真正的杀手级Bug——有它存在就不能发版的Bug——会非常快被消灭。

而在Bug跟踪系统里留下来的绝大部分Bug。就落入了没人管的灰色地带。

用户报告的是Bug吗？不全然是。用户在要求一个新功能或完好某个既有功能吗？也不全然是。好吧，那究竟是什么？

这是一个令人犯难的问题。进一步说，我觉得大部分Bug跟踪系统都在“坑”我们。由于它们让我们非要回答这样的无聊问题，逼着我们站队——要么海菲茨，要么麦考伊斯；要么可口可乐，要么百事可乐。要么是Bug。要么是功能需求——这是一个痛苦的抉择，选择哪一方均在一念之差。由于大部分时候两者皆可。从用户的角度看，Bug和功能需求是没有差别的。

假设你想用一个软件（或者站点）做某件事情，但由于某个功能没有实现而无法完毕。相比于你在使用过程中由于出错而不得不停下来，两者之间有差别吗？

译者注：美剧《Hatfields & McCoys》，又名《血仇》，聚焦于美国声名狼藉的两个家族（Hatfields和McCoys）之争。

两大家族的争执源自于美国南北战争时期，Anse Hatfield和Randall McCoy本是要好的哥们儿，但不想后来生变，二人结下仇怨，甚至引得弗吉尼亚州和肯塔基州都不安宁。

由此，这两大家族联手制造了美国史上最臭名昭著的血腥争端。

我们来看一个样例：在开发Windows应用程序的时候，Visual Studio没有使用正确的字体。

这算是一个Bug还是功能需求呢？

我个人觉得这是一个Bug。我猜微软也是这么觉得的（至少理论上是这样），由于那个问题已经在Microsoft Connect系统里存在了4年多。当你开发一个Windows应用程序。除非你刻意想要使用一种特殊字体，你难道不希望使用操作系统的默认字体吗？好吧，假设你在Visual Studio 2008里创建一个新的窗口。然后加入一个标签控件，看看会是什么情况吧：

仿佛一下子回到了1996年，由于你看到的是“可爱的”MS Sans Serif字体。

那是全部新窗口的默认字体。你也别见怪了，全部新开发的应用程序看起来都丑陋无比——我的措辞已经非常节制了！

以下是一个对照：一行标签用了默认字体，还有一行标签显式设置了默认的GUI字体。

纵观我所使用过的应用软件。我发现，大部分Windows程序猿根本不关心设计。这可不妙！

甚至更糟糕的是。这样的对设计的漠视被Visual Studio携带，从2002年開始不断地感染着每一位用户。

当然，设计方面的问题是非常主观的。在Windows图形用户界面的字体使用方面，要是我们能有一些參考资料。那该多好啊！

某种相似于标准的东西。就比方微软给Windows Vista用户体验定义的那些规范：

• 使用Aero主题和系统字体（Segoe UI）
• 使用通用控件和通用对话框
• 使用标准的窗口边框，慎用透明效果
• ……

这样的规范总共同拥有12条。只是，我想要找的恰恰就是第一条：应用程序应该使用系统字体。

我为Windows Vista的总体质量扼腕叹息。为此我也写过满满的一篇文章。上述这份清单看起来非常欢乐，事实上已经不言而喻。特别是第12条：预留时间提升“总体质量”，让我不禁大笑。在开发Windows Vista的时候。微软想必对这条规范耿耿于怀。值得注意的是，这些都出自于一个热爱Vista的家伙。

对不起。我跑题了。

虽然Visual Studio 2008里的窗口字体行为违背了微软自家的设计规范（中的第一条），这个“Bug”却4年多来一直没有被修正。它被悄悄地归类为“功能需求”。然后被束之高阁了。

毕竟，没什么恶劣影响——使用错误的字体不会让程序崩溃或减少生产力。还有一方面，想象一下，自从微软践踏自家的设计规范以来，有多少大公司的应用软件已经被开发出来了啊。要么由于开发者没有意识到应用程序的字体与操作系统不匹配的问题。要么他们没时间写一些必要的权变代码来加以纠正。

没错。这是一个小问题。

我相信，修正这个问题不会让Visual Studio更好卖。比方多卖给大公司几千个使用授权。这也是它没人管的原因吧。

问题依然：这是一个Bug，还是功能需求？

我非常喜欢用UserVoice（Stack Overflow採用的就是这个工具），它最让我心动的一点是，它有益模糊了Bug与功能需求之间的界线。

无论怎么说，用户搞不明确它们之间的差别。更糟糕的是。程序猿可能会据以搪塞用户。他们把不想做的事情归类为“功能需求”，从此以后就置之不理了。他们会据理力争。嚷嚷着说某个被报告为“Bug”的问题显然不是Bug。自然也就不必修复了。罢了吧，别再区分Bug和功能需求了。让它们都见鬼去吧。

我希望，我们全行业都能少花点时间在概念的口舌之争上，别再煞费苦心地把用户反馈区分成“Bug”或是“功能需求”。面对用户反馈，我们应该多花点时间做一些有建设性的事情。