五個世界 Five Worlds

有一件重要的事幾乎在所有程式設計和軟體開發文獻裡都沒提到，所以我們之間有時會有誤解。

你是個軟體開發者，我也是。不過我們的目標和需要可能並不相同。事實上軟體開發有幾個不同的世界，而且每個世界的規則都不一樣。

去找一本關於 UML 模型的書來看看，裡頭完全不會提到 UML 不適合用於驅動程式。或者你去讀另一篇說「20 MB 執行時期程式庫 [.NET 要用的]並不是問題"的文章，它也並沒有指出明顯的事實：如果在只有 32 KB ROM 的呼叫器上寫程式，這絕對是個問題！

我認為這裡頭有五個世界，雖然偶而有重疊但通常都不會。這五個分別是：

1. 熱縮封膜(Shrinkwrap)軟體
2. 內部用的軟體
3. 嵌入式軟體
4. 遊戲軟體
5. 用後即丟的軟體

當你讀最新的極限程式設計書藉或 Steve McConnell 最好的書，或是 Joel on Software 或軟體開發雜誌，會看到很多有關如何開發軟體的聲明，不過幾乎都不會提到所討論的開發類型，這實在是很不恰當，因為有時候世界不同，做事的方法也會跟著變。

讓我簡短的介紹這些類型。

熱縮封膜軟體是「外頭」很多很多人要用的軟體。可能是用玻璃紙封好在 CompUSA 販售，也可能是透過 Internet 下載的。可以是商業軟體或共享軟體，也可以是開放源碼或 GNU 或其他型式 - 重點是該軟體會被成千甚至數百萬人安裝使用。

熱縮封膜軟體由於兩個特性而衍生出特有的問題：

• 由於使用者很多而且通常都有代替商品，所以使用者介面必須比一般水平更容易才會成功。
• 由於軟體會在很多的電腦上執行，所以程式對電腦間的差異要格外有彈性。上星期某人寄了一封電郵給我，內容是 CityDesk 一個只在波蘭版 Windows 出現的問題，原因是那個作業系統會用右邊的 ALT 鍵輸入特殊字元。我們測過 Windows 95、95OSR2、98、98SE、Me、NT 4.0、Win 2000 還有 Win XP。也測過安裝了 IE 5.01、5.5 或 6.0 的狀況。我們也測了美國、西班牙、法國、希伯來文、和中文各種語文的 Windows。可是就是還沒測到波蘭版。

熱縮封膜軟體有三個主要的分支。開放源碼軟體通常是不支薪的人開發的，而這些人的動力經常會劇烈變動。舉例來說，在全都是志願者的團體中，被認為不「好玩」的事通常沒人會做。另外也如 Matthew Thomas 所指出會降低可使用性。開發動作很可能是分散在各地進行，導致團隊溝通的品質參差不齊。在開放源碼世界很少會面對面在白板旁一邊畫著框框和箭頭一邊討論，所以這類專案在需要畫圖溝通的設計決策上通常都做得很差。因此這種地域分散團隊在複製現有軟體時做得會好很多，因為抄現有的軟體就不太需要設計了。

顧問軟體是另一種熱縮封膜軟體分支，由於需要很大量的客製化和安裝，所以得用恐怖的價錢請一整批顧問來安裝。客戶關係管理(CRM)和內容管理系統(CMS)軟體通常都屬於這一類。有些人會覺得這些軟體其實什麼事都做不了，只不過是找一群顧問進來每小時付 300 美元的藉口罷了。雖然顧問軟體裝得像熱縮封膜軟體，不過由於安裝啟用的成本太高，其實比較像內部用的軟體。

像 Salesforce.com 或 eBay 之類的 Web 商業軟體還是必須容易使用並能在很多瀏覽器上執行。雖然開發者比較幸運，能或多或少控制所部署的環境(位於資料中心的電腦)，不過還是得處理各種瀏覽器間廣泛的差異，以及大量的使用者。因此我認為它基本上算是熱縮封膜軟體的一支。

內部用軟體只考慮一種狀況，在一家公司的電腦能跑就好了，因此開發起來容易多了。你可以對執行環境做各種的假設。你可以要求某個版本的 Internet Explorer 或微軟 Office 或 Windows。如果你需要畫圖表，呼叫 Excel 來畫就好了；我們部門裡每個人都有 Excel。(不過在熱縮封膜軟體這樣做的話，潛在客戶大概會跑掉一半。)

在這裡可使用度並不重要，因為必須使用的人數有限，反正也沒有其他選擇就只能將就。開發速度會更加重要。由於開發投入的價值只侷限於一家公司，能用的資源相對上也少了許多。微軟花得起五億美元開發一套對一般人只值 80 美元的作業系統。不過當 Detroit Edison(譯註：能源公司)開發一個能源交易平台時，投入的成本就必須適合單一家公司。要得到合理的投資報酬率就不能像熱縮封膜軟體一樣花錢。所以很悲哀的，很多內部用軟體都爛到不能再爛。

嵌入式軟體具備一個特性，它會被放在硬體裡而且幾乎都不能更新。這可是個完全不同的世界。由於沒有第二次機會，品質要求比平常高出許多。你可能得用一顆比一般桌上型處理器慢上許多處理器，所以得花很多時間做最佳化。程式漂不漂亮沒關係，跑得快才重要。可用的輸入及輸出裝置可能也很少。

上週租的車上有裝全球定位系統(GPS)，不過上面的輸入/輸出很差，幾乎不能用。你曾試過用這種玩意輸入位址嗎？他們在螢幕上畫了一個「鍵盤」，你必須用方向鍵從五個小矩陣(每個裡面各有 9 個字母)選出要的字母。(我自己車上的 GPS 有觸控螢幕，使用介面就好很多多。不過離題了。)

把遊戲軟體獨立算一類有兩個原因。首先遊戲開發的經濟是打擊導向的。有些遊戲擊出安打，更多的遊戲被三振，如果你想在遊戲業賺錢就得瞭解這一點，然後確定你有多個遊戲，才能用大賺的錢去平衡失敗的損失。這其實比較像電影業而不是軟體業。

遊戲開發更大的問題是只能有一個版本。當使用者玩完毀滅公爵 3D 版本，並不會因為修正了某些問題或增加新武器而升級成毀滅公爵 3.1D。除了少數例外，一般玩完一個遊戲後再重玩是很無聊的。所以遊戲的品質要求和嵌入式軟體相當，又要有足夠的錢一次就把東西做好。熱縮封膜軟體開發者就幸福多了，如果 1.0 版不符合大家的需求，再出個 2.0 版或許就可以了。

最後用後即丟軟體是只為了得到其他東西而暫時創造的軟體，當你達到目的之後永遠都不會再用到。舉例來說，你可能會為了其他需要，寫一個小命令腳本把某個輸入檔案轉成需要的格式，這就是只用一次的操作。

或許還有其他我忘記的軟體開發類型。

這裡要講一件重要的事情。當你閱讀那些由專業軟體開發大師或顧問撰寫的程式設計方法書時，可以放心認定書裡說的都是企業內部用的軟體開發。不是熱縮封膜軟體，不是嵌入式軟體當然也不會是遊戲軟體。為什麼呢？因為這些大師都是企業在請的，是企業在付他們的薪水。(相信我吧，id software 是不會請 Ed Yourdon 去教結構化分析的。)

上星期 Kent Beck 聲稱如果實施極限程式設計的話，就不需要錯誤追蹤系統。因為成對程式設計(持續進行程式碼檢視)和測試導向開發(保證 100% 的自動測試涵蓋率)的結合，讓你幾乎不會出現問題。這我可就聽不懂了。於是就到我們自己 Fog Creek 的錯誤追蹤資料庫裡看看究竟都是在忙些什麼問題。

瞧，我發現這些問題絕少能被成對程式設計或測試導向開發找出。我們很多的「問題」基本上就是 XP 所謂的 story，只是功能要求。我們用問題追蹤資料庫來記錄要實作的大小功能和改善，並且用它來管理這些工作並排定優先順序。

其他很多問題都是只會在外頭經過大量使用後再會發現。比如波蘭鍵盤的問題。這種東西成對程式設計是不可能發現的。還有那麼我們未曾發生，把不同功能一起運作時才出現的邏輯錯誤。程式愈大愈複雜，功能間的未考慮到的互動就會愈多。一個很少出現的特別字元序列({${?，如果你一定要知道的話)讓字彙分析器錯亂了。有些 ftp 伺服器在刪除不存在的檔案時會出錯(我們的 ftp 伺服器不會有事，所以我們從來沒遇到過。)

我很小心的看過每一個問題。在 CityDesk 更新版所修正的 106 個問題中，只有 5 個可以藉由搭擋程式設計或測試導向設計來預防。事實上我們知道而且覺得沒關係(這只能讓我們的客戶來指正！)的問題遠比 XP 方法能抓到的要多。

不過就其他開發類型來說 Kent 是對的。就大部份的企業開發應用而言，上面這些東西都不算問題。輸入不合法時程式會當掉？重新執行一次，這次注意不要輸入{${?了！另外我們只有一種 FTP 伺服器而且全公司都沒有人在用波蘭版的 Windows。

不管在做什麼專案，大部份軟體開發的事情都是一樣的，不過並不是每件事都是。當某人告訴你某個方法並認為可以用於你正在做的工作時。先想想這個傢伙是打哪來的。Steve McConnell、Steve Maguire 還有我都來自相同的小角落：一個在華盛頓州雷蒙撰寫客戶眾多的試算表應用程式的世界。因此我們對容易使用有很高的要求，同時要求問題的數目要少。其他方法論大師的工作是企業內部開發的顧問，所以他們會說那些話。不管如何，我們都應該能由對方身上學到一些東西。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.