|
|
|
|
别再纠结是Bug还是新需求了 |
| |
|
作者 陆其明 火龙果软件 发布于 2014-11-04 |
|
|
|
有它存在就不能发版的真正Bug会很快被消灭，而在Bug跟踪系统留下来的绝大部分Bug，就落入了没人管的灰色地带。用户报告的是Bug吗？不完全是。用户在要求新功能或完善某既有功能吗？也不完全是。好吧，那到底是什么？
自从我干上软件开发这一行，并且使用了Bug跟踪系统，我们在每一个项目里都会纠结一个基本的问题：你怎么能把Bug与功能需求区分开来？
当然，如果程序崩溃了，这毫无疑问是Bug。不过，那也许只占你每天所处理问题的10%。为了避免项目的彻底失败，真正的杀手级Bug——有它存在就不能发版的Bug——会很快被消灭。而在Bug跟踪系统里留下来的绝大部分Bug，就落入了没人管的灰色地带。用户报告的是Bug吗？不完全是。用户在要求一个新功能或完善某个既有功能吗？也不完全是。好吧，那到底是什么？
这是一个令人犯难的问题。进一步说，我认为大部分Bug跟踪系统都在“坑”我们，因为它们让我们非要回答这种无聊问题，逼着我们站队——要么海菲茨，要么麦考伊斯（（译者注请见文末）；要么可口可乐，要么百事可乐；要么是Bug，要么是功能需求——这是一个痛苦的抉择，选择哪一方均在一念之差，因为大部分时候两者皆可。从用户的角度看，Bug和功能需求是没有区别的。如果你想用一个软件（或者网站）做某件事情，但因为某个功能没有实现而无法完成；相比于你在使用过程中因为出错而不得不停下来，两者之间有区别吗？
我们来看一个例子：在开发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”或是“功能需求”。面对用户反馈，我们应该多花点时间做一些有建设性的事情。
|
|
|
|
|
