工匠技藝 Craftsmanship

軟體製作並不是種生產程序。在 1980 年代每個人都在心驚膽跳，害怕日本軟體公司建立「軟體工廠」，然後用生產線大量製造出高品質的程式。這在當時行不通，現在也一樣行不通。把一大群程式師塞進一個房間再排得整整齊齊的，並沒有真正的降低臭蟲的數目。

如果寫程式並不是生產線式的製造行為，那究竟是什麼呢？有些人曾經提議稱之為工匠技藝(craftsmanship)。這也並不算對，因為我不在乎你說什麼，Windows 裡詢問要如何索引說明檔的對話盒絕對稱不上是「工匠技藝」，連一點邊都沾不上。

寫程式並不是量產也不全是工匠技藝(雖然可以是)，它是種設計。設計是那種價值比成本增加得快的朦朧區域。紐約時報雜誌已經大肆吹捧過 iPod，還說蘋果是少數知道如何利用良好設計提升價值的公司。不過設計我也談夠了，現在想來談談工匠技藝，談談什麼是工匠技藝以及要如何辨別。

我想想來談談我為 CityDesk 3.0 重寫的一段程式：檔案匯入程式。(廣告：CityDesk 是本公司出品的很容易用的內容管理產品。)

它的規格似乎和任何一段程式碼一樣簡單。使用者用標準對話盒選擇一個檔案，然後程式將該檔案複製到 CityDesk 的資料庫中。

結果卻變成「最後 1% 程式用掉 90% 時間」的最佳範例。最早一版的程式結構大概是這樣子的:

1. 開檔案
2. 把內容全部讀進來，放在一個大位元組陣列裡
3. 把位元組陣列放在一個記錄中

效果不錯。大小合理的檔案幾乎是一瞬間就做好了。它有幾個小問題，我們一個一個來看。

當我把一個 120 MB 的檔案丟進 CityDesk 時跑出第一個問題。通常人們不太會在網站上放個 120 MB 的檔案。事實上應該是少之又少才對。不過雖然少但還是有可能。程式可以用，不過等了一分鐘而且畫面上完全沒有反應 - 程式就這樣定住不動，看起來好像完全當掉了。這顯然並不太理想。

由使用介面的觀點來看，我真正要的是在長時間處理時出現一個進度棒之類的東西再加上一個取消鈕。理想的狀況下，你可以在 CityDesk 裡繼續其他操作，檔案複製的作業會在背景執行。這有三種顯而易見的方法可以達成：

1. 只用一個執行緒，由該執行緒經常輪詢輸入事件
2. 啟用第二個執行緒，然後小心的進行同步
3. 啟用第二個行程，然後不必那麼小心的進行同步

我的經驗是第一種作法行不通。要確定應用程式裡所有程式碼都能在複製檔案時安全的執行，實在是太困難了。另外 Eric S. Raymond 也讓我相信，以解決方案來說執行緒通常不如單獨的行程好：事實上多年的經驗顯示，多執行緒程式設計產生了很多額外的複雜性，而且會引入全新種類的危險海森堡蟲(heisenbugs)。第三項似乎是個好答案，尤其當我們下層用的是多使用者的資料庫，不用怕很多行程同時使用。所以我打算等感恩節休假結束就用第三種作法。

不過整體想想看就會發現，我們已經由讀檔寫作資料庫變成複雜許多的東西：啟動一個子行程，讓它讀檔寫入資料庫，這個子行程還要有一個進度棒和取消鈕，最後還要某種機制讓子行程通知母行程，檔案已經處理完可以顯示.. 其他的工作還包括將命令列參數傳給子行程，確定視窗焦點的行為正確，還要能處理使用者在複製檔案時關機的狀況。我猜等把這些都做好，大概要十倍的程式才能優雅地處理大檔案，而這可能只是使用者所看到的程式的百分之一。

當然會有某類型的程式師出來爭論，說我用子行程的新架構比原本的差。這種作法「過度膨脹」(由於那些額外增加的程式碼)。另外潛在的問題也比較多(一樣由於是多加的程式碼)。這個作法做太過頭了。這某種程度也表示 Windows 的確是個爛作業系統。他們會說這和進度棒有什麼關係？他們會嘲笑著說：只要按 Ctrl+Z 再重複打 "ls -l" 看看檔案大小有沒有增加就好啦！

這個故事的教訓是修正一個 1% 的問題可能會用掉 500% 的工夫。這種狀況並不只軟體業會發生。敢這樣講是因為我現在就在管理這些建築工程。上星期我們的包商終於完成 Fog Creek 新辦公室的最後修飾工程。內容包括在前門安裝閃亮的藍色壓克力，旁邊圍著鋁框，鋁框上每 20 公分就鑲有一顆螺絲。如果你仔細看照片，會發現每片門都會被鋁框整個包住，當門關起來時，兩片直框會併排在一起。雖然圖上看不出來，不過中間鋁條上的螺絲幾乎但沒有確實對齊。差了大概有 2 公釐。負責這件事的木匠很小心的測量，不過裝鋁框時門是放在地上，並不是等好門裝好再當場裝的。所以等到要把門裝上去時，才發現螺絲並沒有對齊。

這或許並不罕見; 我們辦公室裡很多門的螺絲都沒有對的很好。問題是當洞鑽好之後，要重新修正的代價貴得離譜。由於正確的螺絲位置離原來的洞只有幾公釐，所以不能直接在門上再鑽一個，可能得把整個門換掉才能解決。這實在是很不值得。這正是另一個修正 1% 的問題會用掉 500% 工夫的例子，而且這也解釋了為何這世上很多人造物都是 99% 好而非 100% 完美。(不過建築師倒是不斷吹噓，說某些亞歷桑那州的高貴金屋裡每根螺絲都排得很整齊。)

這點出了軟體的一項特性，一項大部份人都視為工匠技藝的特性。當軟體是由真正的工匠製作時，所有螺絲都會對得整整齊齊.. 當你做些很罕見的事時，應用程式會表現得很聰明。作者會投入更多的工夫去正確處理特的狀況，而不光是讓主要的程式會動。即使要額外再花 500% 的力氣去處理 1% 的狀況也在所不惜。

工匠技藝當然是非常昂貴的。唯一負擔得起的方法就是針對大量的客戶開發軟體。很抱歉，不過保險公司開發的內部人事管理程式絕對不可能達到這種工藝的境界，因為就是沒有足夠的使用者來分散額外的成本。不過就套裝軟體公司而言，這種工藝境界可以讓使用者高興並提供長期的競爭優勢，所以我願意花時間並正確地執行。請容忍我吧。

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