自從我干上軟件開發(fā)這一行，并且使用了Bug跟蹤系統(tǒng)，我們在每一個項目里都會糾結(jié)一個基本的問題：你怎么能把Bug與功能需求區(qū)分開來？

當然，如果程序崩潰了，這毫無疑問是Bug。不過，那也許只占你每天所處理問題的10%。為了避免項目的徹底失敗，真正的殺手級Bug——有它存在就不能發(fā)版的Bug——會很快被消滅。而在Bug跟蹤系統(tǒng)里留下來的絕大部分Bug，就落入了沒人管的灰色地帶。用戶報告的是Bug嗎？不完全是。用戶在要求一個新功能或完善某個既有功能嗎？也不完全是。好吧，那到底是什么？

這是一個令人犯難的問題。進一步說，我認為大部分Bug跟蹤系統(tǒng)都在“坑”我們，因為它們讓我們非要回答這種無聊問題，逼著我們站隊——要么海菲茨，要么麥考伊斯；要么可口可樂，要么百事可樂；要么是Bug，要么是功能需求——這是一個痛苦的抉擇，選擇哪一方均在一念之差，因為大部分時候兩者皆可。從用戶的角度看，Bug和功能需求是沒有區(qū)別的。如果你想用一個軟件（或者網(wǎng)站）做某件事情，但因為某個功能沒有實現(xiàn)而無法完成；相比于你在使用過程中因為出錯而不得不停下來，兩者之間有區(qū)別嗎？

（譯者注：美劇《Hatfields & McCoys》，又名《血仇》，聚焦于美國聲名狼藉的兩個家族（Hatfields和McCoys）之爭。兩大家族的爭執(zhí)源自于美國南北戰(zhàn)爭時期，Anse Hatfield和Randall McCoy本是要好的哥們兒，但不想后來生變，二人結(jié)下仇怨，甚至引得弗吉尼亞州和肯塔基州都不安寧。由此，這兩大家族聯(lián)手制造了美國史上最臭名昭著的血腥爭端。）

我們來看一個例子：在開發(fā)Windows應(yīng)用程序的時候，Visual Studio沒有使用正確的字體。這算是一個Bug還是功能需求呢？

我個人覺得這是一個Bug。我猜微軟也是這么認為的（至少理論上是這樣），因為那個問題已經(jīng)在Microsoft Connect系統(tǒng)里存在了4年多。當你開發(fā)一個Windows應(yīng)用程序，除非你刻意想要使用一種特殊字體，你難道不希望使用操作系統(tǒng)的默認字體嗎？好吧，如果你在Visual Studio 2008里創(chuàng)建一個新的窗體，然后添加一個標簽控件，看看會是什么情況吧：

仿佛一下子回到了1996年，因為你看到的是“可愛的”MS Sans Serif字體。那是所有新窗體的默認字體。你也別見怪了，所有新開發(fā)的應(yīng)用程序看起來都丑陋無比——我的措辭已經(jīng)很克制了！

下面是一個對比：一行標簽用了默認字體，另一行標簽顯式設(shè)置了默認的GUI字體。

縱觀我所使用過的應(yīng)用軟件，我發(fā)現(xiàn)，大部分Windows程序員根本不關(guān)心設(shè)計。這可不妙！甚至更糟糕的是，這種對設(shè)計的漠視被Visual Studio攜帶，從2002年開始不斷地感染著每一位用戶。

當然，設(shè)計方面的問題是很主觀的。在Windows圖形用戶界面的字體使用方面，要是我們能有一些參考資料，那該多好啊！某種類似于標準的東西。就比如微軟給Windows Vista用戶體驗定義的那些規(guī)范：

使用Aero主題和系統(tǒng)字體（Segoe UI）

使用通用控件和通用對話框

使用標準的窗體邊框，慎用透明效果

……

這樣的規(guī)范總共有12條。不過，我想要找的恰恰就是***條：應(yīng)用程序應(yīng)該使用系統(tǒng)字體。

我為Windows Vista的整體質(zhì)量扼腕嘆息，為此我也寫過滿滿的一篇文章。上述這份清單看起來很歡樂，其實已經(jīng)不言而喻。特別是第12條：預(yù)留時間提升“整體質(zhì)量”，讓我不禁大笑。在開發(fā)Windows Vista的時候，微軟想必對這條規(guī)范耿耿于懷。值得注意的是，這些都出自于一個熱愛Vista的家伙。

對不起，我跑題了。

盡管Visual Studio 2008里的窗口字體行為違背了微軟自家的設(shè)計規(guī)范（中的***條），這個“Bug”卻4年多來一直沒有被修正。它被悄悄地歸類為“功能需求”，然后被束之高閣了。畢竟，沒什么惡劣影響——使用錯誤的字體不會讓程序崩潰或降低生產(chǎn)力。另一方面，想象一下，自從微軟踐踏自家的設(shè)計規(guī)范以來，有多少大公司的應(yīng)用軟件已經(jīng)被開發(fā)出來了啊。要么因為開發(fā)人員沒有意識到應(yīng)用程序的字體與操作系統(tǒng)不匹配的問題，要么他們沒時間寫一些必要的權(quán)變代碼來加以糾正。

沒錯，這是一個小問題。我相信，修正這個問題不會讓Visual Studio更好賣，比如多賣給大公司幾千個使用授權(quán)。這也是它沒人管的原因吧。

問題依舊：這是一個Bug，還是功能需求？

我很喜歡用UserVoice（Stack Overflow采用的就是這個工具），它最讓我心動的一點是，它故意模糊了Bug與功能需求之間的界線。不管怎么說，用戶搞不明白它們之間的區(qū)別；更糟糕的是，程序員可能會據(jù)以搪塞用戶。他們把不想做的事情歸類為“功能需求”，從此以后就置之不理了。他們會據(jù)理力爭，嚷嚷著說某個被報告為“Bug”的問題顯然不是Bug，自然也就不必修復(fù)了。罷了吧，別再區(qū)分Bug和功能需求了，讓它們都見鬼去吧！

我希望，我們?nèi)袠I(yè)都能少花點時間在概念的口舌之爭上，別再煞費苦心地把用戶反饋區(qū)分成“Bug”或是“功能需求”。面對用戶反饋，我們應(yīng)該多花點時間做一些有建設(shè)性的事情。

本文鏈接：http://blog.csdn.net/happydeer/article/details/40661515