别再纠结是Bug还是新需求了.pdfVIP

别再纠结是Bug还是新需求了 自从我干上软件开发这一行 ，并且使用了Bug跟踪系统 ，我 在每一个项目里都会纠结一个基本的 问题 ：你怎么能把Bug与功能需求区分开来? 当然 ，如果程序崩溃了 ，这毫无疑问是Bug。不过 ，那也许只占你每天所处理问题的10%。为了避 免项目的彻底失败 ，真正的杀手级Bug——有它存在就不能发版的Bug——会很快被消灭。而在Bug 跟踪系统里留下来的绝大部分Bug ，就落入了没人管的灰色地带。用户报告的是Bug吗?不完全是。 用户在要求一个新功能或完善某个既有功能吗?也不完全是。好吧 ，那到底是什么? 这是一个令人犯难的问题。进一步说 ，我认为大部分Bug跟踪系统都在“坑”我 ，因为它 让我 非 要回答这种无聊问题 ，逼着我 站队——要么海菲茨 ，要么麦考伊斯((译者注请见文末);要么可口 可乐 ，要么百事可乐;要么是Bug ，要么是功能需求——这是一个痛苦的抉择 ，选择哪一方均在一念 之差 ，因为大部分时候两者皆可。从用户的角度看 ，Bug和功能需求是没有区别的。如果你想用一 个软件(或者网站)做某件事情 ，但因为某个功能没有实现而无法完成;相比于你在使用过程中因为出 错而不得不停下来 ，两者之间有区别吗? 我 来看一个例子 ：在开发W indows应用程序的时候 ，Visual St udio没有使用正确的字体。这算是 一个Bug还是功能需求呢? 我个人觉得这是一个Bug。我猜微软也是这么认为的(至少理论上是这样) ，因为那个问题已经 在Microsof t Co nn ct系统里存在了4年多。当你开发一个W indows应用程序 ，除非你刻意想要使用 一种特殊字体 ，你难道不希望使用操作系统的默认字体吗?好吧 ，如果你在Visual St udio 2008里创 建一个新的窗体 ，然后添加一个标签控件 ，看看会是什么情况吧 ： 仿佛一下子回到了1996年 ，因为你看到的是“可爱的”MS Sans S rif 字体。那是所有新窗体的默认 字体。你也别见怪了 ，所有新开发的应用程序看起来都丑陋无比——我的措辞已经很克制了! 下面是一个对比 ：一行标签用了默认字体 ，另一行标签显式设置了默认的GUI字体。 纵观我所使用过的应用软件 ，我发现 ，大部分W indows程序员根本不关心设计。这可不妙!甚至更糟 糕的是 ，这种对设计的漠视被Visual St udio携带 ，从2002年开始不断地感染着每一位用户。 当然 ，设计方面的问题是很主观的。在W indows图形用户界面的字体使用方面 ，要是我 能有一些 参考资料 ，那该多好啊!某种类似于标准的东西。就比如微软给W indows Vist a用户体验定义的那些 规范 ： 使用A ro主题和系统字体(S go UI) 使用通用控件和通用对话框 使用标准的窗体边框 ，慎用透明效果…… 这样的规范总共有12条。不过 ，我想要找的恰恰就是第一条 ：应用程序应该使用系统字体。 我为W indows Vist a的整体质量扼腕叹息 ，为此我也写过满满的一篇文章。上述这份清单看起来很 欢乐 ，其实已经不言而喻。特别是第12条 ：预留时间提升“整体质量” ，让我不禁大笑。在开 发W indows Vist a的时候 ，微软想必对这条规范耿耿于怀。值得注意的是 ，这些都出自于一个热 爱Vist a的家伙。 对不起 ，我跑题了。 尽管Visual St udio 2008里的窗口字体行为违背了微软自家的设计规范(中的第一条) ，这个“Bug”却4 年多来一直没有被修正。它被悄悄地归类为“功能需求” ，然后被束之高阁了。毕竟 ，没什么恶劣影 响——使用错误的字体不会让程序崩溃或降低生产力。另一方面 ，想象一下 ，自从微软践踏自家的 设计规范以来 ，有多少大公司的应用软件已经被开发出来了啊。要么因为开发人员没有意识到应用 程序的字体与操作系统不匹配的问题 ，要么他 没时间写一些必要的权变代码来加以纠正。 没错 ，这是一个小问题。我相信 ，修正这个问题不会让Visual St udio更好卖 ，比如多卖给大公司几 千个使用授权。这也是它没人管的原因吧。 问题依旧 ：这是一个Bug ，还是功能需求? 我很喜欢用Us rVo ic (St ack Ov rf low采用的就是这个工具) ，它最让我心动的一点是 ，它故意模糊 了Bug与功能需求之间的界线。不管怎么说 ，用户搞不明白它 之间的区别;更糟糕的是 ，程序员可 能会据以搪塞用户。他 把不想做的事情归类为“功能需求” ，从