說說軟體開發這個職業

    有時，一個問題的真正價值並不在於找到答案，而在於通過考查這個問題引出其他或許更有價值的問題。另外，有時候發現一個無人問津的問題，也可能會幫助我們看到一些未被發現的機會，從而引出更深遠、更有價值的發現。

我已經“搞軟體”很長時間了，我覺得我們這個行業已經到了“回頭看看”的時候了，此時回顧一下我們工作的基本性質可能是一件非常有用的事情。

人類製作軟體已經有多久的歷史了

像很多問題一樣，這個問題的答案是“要看情況”。製作軟體的概念都包括什麼？是否包括最早期由繞線PC板和交換管構成的程式設計？是否包括提花織機？

    也許不包括。但使用穿孔卡片和大型主機進行資料處理的那段時期是否應該包括進來呢？那時人們使用穿孔卡片或磁帶輸入，使用印表機輸出，沒有互動，沒有VDT，為了看看程式是否正確執行，需要通宵等待。

    為了便於本書的討論，我認為軟體製作應該從20世紀70年代中後期開始算起，那時小型桌面系統剛剛問世，我們開始開發供人們直接使用的互動式軟體。

    這並不是說我認為資料處理不夠重要、不夠有趣，或不夠複雜，只是過去他們的資料處理方法與我們現在的資料處理方法之間的差別實在是太大了，以至於我看不到其間存在智慧的傳承。這就像是騎馬與開車一樣：二者都是複雜的活動，都需要知識和技巧，但學會了一樣實際上並不能幫助你學會另一樣。

    但是先等一下！物件導向（OO）語言和技術的出現又該如何看待呢？它們與過去一度盛行的過程語言（例如C和Pascal）可是正好相反啊。OO出現之前的過程語言時代也應該被看作是一種完全不同的活動嗎？

    我不這樣認為。事實上，我覺得我們現在所說的物件導向技術很大一部分是在過程程式設計技術成熟的基礎上產生的。從根本上講，正是在過程語言的最佳實踐得到了良好的運用之後，才引出了面嚮物件語言中最基本的概念。

    事實上，我覺得物件導向作為一種程式設計方式早在面嚮物件語言出現之前就開始被人們使用了。現在，我只需說“物件導向正規化與過程語言正規化共享很多思想”就夠了。假定我們都同意這個觀點，那麼我還要將結構化程式設計的時代包括進來，作為軟體製作歷史的一部分。（有關這方面的討論請參閱第4章。）這樣，我就可以說軟體製作的歷史大約為30～35年。

    好了，下面來談另一個問題。

軟體開發是一種什麼樣的活動

    它是一種職業，一門手藝，一個專業，還有別的嗎？有人可能說它是一門藝術或科學，有人可能說它是工程，還有人會說它是演繹邏輯的一個分支。我相信這個問題的價值主要並不在於找到答案，而在於通過這個問題引發其他問題。

    人們有很多詞語來形容他們賴以謀生併為身邊的世界做出貢獻的事情，例如工作、勞動、行業、手藝、副業、技能、追求、技藝、職業、專業，等等。不同的人用不同的方式來使用這些詞語，使用時也伴隨著一些被人們廣泛接受的暗示、區別、期望和假設。

    就拿培訓來說吧。大多數人都會把“需要大量培訓”與專業或行業的概念聯絡到一起，而不是一般的勞動或工作①。這並不是說所有工作都很簡單，但進入某個專業或行業肯定有非常嚴格的要求，不會像隨便找一份工作一樣。

    另一個區別是許可與監督。醫生、律師、會計師、承包商等都需要國家發給從業許可，以確保他們能夠勝任，並確保他們的技能和培訓已達到一個最低標準。通常，這是因為如果他們不勝任的話，會造成嚴重的損害。當然，這也暗示著存在一套公認的標準，是這些專業人員可以掌握的，而且這些標準都是正確的。

    此外，由於他們需要達到這些嚴格的要求和標準，因此專業人員（和工匠）組成了各種支援性組織（協會、聯盟和專業組織），為專業人員提供支援並幫助他們獲得成功。這些組織也提供了一個積累集體智慧和知識的集中場所，從而保持行業的持續發展，並讓知識代代相傳。

    當一個人從事複雜（有時甚至關乎生命）的工作時，有這種支援是非常有利的。它可以讓專業人員知道自己在一些重要方面是否符合標準，以及如果不符合標準該怎麼辦。對於那些接受專業人員服務的人來說，好處也是很明顯的。比如，在我看來，我的醫生知道自己在做什麼，這是很重要的，而且有其他人（最好不是我）能證實他是否勝任，這也同樣重要。

    此外，專業還傾向於發展出專門的、高度專業的語言。例如，醫生把闌尾切除手術叫做“appendectomy”，而把結腸切除手術叫做“colostomy”。為什麼一個字尾用“-ectomy”而另一個字尾用“-ostomy”呢？我不知道，但醫生們肯定知道，而且我打賭這個區別對於醫生們來說很重要。而我們所知道的只不過是我們的某個器官被切除了。

    因此，我在這裡有點武斷地決定用“專業”這個詞來表示一個需要大量、長期培訓的職業，它擁有專門的語言，用來描述專業人員所做的事情，並使得他們可以高度精確地互相交流，而且專業通常還有一種為從業人員提供支援的專業組織。專業的背後有大量的傳統、明確的實踐和支援團體，以及供所有成員共享的集體智慧。專業提供了對活動和想法的同行評審，還提供了許可或認證過程，這通常作為專業學科的一部分，以便給予專業人員信心，並使得那些接受他們服務的人感到放心。

    而且，如果你想成為一名醫生、律師或傢俱製作大師，你需要遵循一個明確定義的路徑。當社會需要更多這樣的人時，我們知道培養他們的過程，也知道如何指導年輕人為某個專業生涯做準備。

    那麼軟體開發屬於哪一類呢？

    軟體開發當然很複雜，需要大量的培訓和經驗才能做好。並不是每個人都能夠從事軟體開發，這並非因為它超過了某些人的能力，而是因為並非每個人都想從事或長期堅持從事這個職業。它需要一定的特質，還需要愛好技術並熱衷於解決問題，這些特點不是每個人都具備的。此外，隨著時間的推移，人們成立了許多支援性的組織，軟體開發人員在這裡尋求共享他們的知識和工作方法。整個開源運動就是一個例子，它是由軟體開發人員共同管理的，例如Java使用者組和.Net程式設計師學習小組。開發人員幾乎都是用自己的力量來支援這些工作，因為他們認為這樣的組織是有價值的。

    因此，我可以說軟體開發從本質上說是一項專業活動。無論我們是否已經把它當作一項專業，我們都應該這樣做。我們暫時不考慮它是否應該被納入政府管理這個問題，因為這裡的重點是弄清楚軟體開發作為一個專業應該提供的東西，這些東西使得軟體開發人員直接受益，並有助於提高他們所開發軟體的質量。

    如果你能同意上述觀點，那麼請接著往下讀。

    我們建立軟體的時間並不長。而其他大多數專業和工藝都有數百年乃至數千年的歷史，並且長時間以來形成了支援這些專業的基礎。

    例如，想象一下當醫學只有35年曆史時是什麼樣子的。我能想到的是巫師把水蛭吸附到人身上，不斷地搖動撥浪鼓，用放血的手段實現治療的目的。有趣的是，那時的醫學確實做到了一定程度的成功。事實證明失血可以減輕發燒，儘管這不是一個非常好的退熱方法（有時甚至會使人因失血過多而死亡）。即便在今天，醫生的治療效果在很大程度上也與病人對醫學的信任、病人認為接受的治療會讓他變好的信心密切相關。

    因此，巫醫有時也能看好病，只是這不常發生。治療過程也並非絕對地可靠和可預測，這是不是聽上去很熟悉？

    此外，在軟體開發的35年曆史中，在計算能力以及商業和日常生活與軟體的關係等方面發生了多大的變化？人們現在的身體與醫學剛剛出現時的身體基本是完全一樣的，因此醫生可以大量依靠過去的做法和發現，同時學習新技術，把專業水平推向前進。我們卻沒有這份奢侈，現在的計算機與短短几年前的計算機就完全不同了。例如，計算機的速度已經快了幾個數量級。而且，當我剛開始編寫軟體時，像磁碟儲存空間和記憶體這樣的關鍵資源不僅非常昂貴，而且十分有限（那時根本沒有100GB的硬碟，你有錢也買不到）。如果我們後退足夠長的時間（實際上也沒有多久），能夠與計算機打交道的人只有那些受過訓練的、技能嫻熟的操作員。是的，這些都是很大的、漸進式的變革，但變化是一個基本現實，甚至一個人的整個職業生涯都在經歷變化。

    因此，有多大可能把“製作軟體”這件事完全做對呢？我認為可能性非常小。事實上，考慮到軟體開發可能仍處在“水蛭加撥浪鼓療法”的初級階段（至少在一定程度上是這樣的），因此我們能做開發就已經很不錯了。

    換言之，我想說的是軟體應該被當作一個專業活動來做，但事實上人們並沒有這樣做，至少專業化程度不高。

軟體開發缺少了什麼

    讓我們把軟體開發與其他專業做一下對比。

    專業語言。在軟體開發中，語言總是傾向於實施細節的。像“迴路”、“轉換”、“中止”和“異常”這樣的詞雖然是專用的，但卻都是針對很低層次的。木匠大工在吩咐小工如何做一個榫卯結構時，不會用角度和英寸來說明。術語本身就說明了所有規格，也說明了為什麼要把東西做成這樣或那樣，你將會遇到什麼難處和機會，以及選擇這條路之後會得到或失去什麼。這種高階的專業語言幫助專業人員做出更好的決策，而且常常是集體決策。這裡我要發表的看法之一是設計模式運動就是為軟體開發工作增加高階專業語言的一種嘗試，目的是提高我們的專業水平。這倒並不一定是這項運動背後的目的，但事實證明它在這方面確實做出了巨大的貢獻，或許是無意的。我認為這也部分地解釋了模式和模式書籍流行的原因。我想很多人都認識到了我們的工作中、我們的思考和交流方式中缺少什麼東西。能夠傾聽這種內心的直覺，說明我們在專業化方面正在走向成熟。

    一個進入專業的明確路徑。如果有人問你“要想成為軟體開發人員，應該做什麼”，你將如何回答他們？上大學？閱讀幾本書籍？通過某廠商的認證？還是先找一份工作濫竽充數，直到你能夠做軟體？如果你想成為一名成功的民事律師，那麼我至少可以大體上告訴你應該怎樣做。首先讀大學（法學院），然後在一個法律機構實習並通過律師資格考試，成為一名助理律師，最後再朝著一名正式合夥律師努力。你想成為一名刑事律師嗎？有類似但不同的步驟，但這些路線都是明確定義的。我的一位同事Adam Milligan這樣說：“我們有醫學院、法學院，但開發學院在哪裡？”沒有開發學院。醫院聘用住院實習醫生，以便讓經驗豐富的醫生來培訓這些新人。醫院懂得，如果想培養新的醫生，提高他們的醫術，以便確保病人健康和幸福，就必須這樣做。軟體開發尚未採用這種做法，但實際上也需要這麼做。

    同行評議。醫生和律師都有同行評議的期刊及其他為專業人員提供支援的機制。這些機制使得專業人員可以把專業推向前進，並且可以對新的實踐和程式進行現實核查。

    軟體開發中也有類似的資源，但都非常雜亂無章，而且沒有得到良好的組織。你可以在Google上搜尋一個問題，在Usenet上尋求答案，但得到的結果卻十分凌亂。前面提到的很多使用者組和學習小組作為“草根”一族正在進行著建立軟體業同行評議的基本嘗試。部落格的廣泛使用也同樣如此，人們通過部落格來分享軟體的思想和智慧，人們做了很多了不起的嘗試，但都是混亂無序的。

    標準和實踐。醫生有一些特定的操作，遵循這些操作，醫生們可以保證一定程度的成功，至少可以確保不失敗。例如，醫生知道清潔是非常重要的。他們對器械進行消毒，並且在為病人治療前仔細地洗手。

    但醫生們也並非從一開始就知道這一點。直到19世紀的中後期，外科醫生在為病人做手術之前還都是嫌麻煩，不願意去洗手或清洗器械，結果，他們治療的失敗率（病人的死亡率）就比正常應有的失敗率高得多。匈牙利裔醫生Ignaz Semmelweis1860年在維也納的一個接生所工作時提出，有一些微小的、肉眼看不到的東西會使人們患病，因此醫生應該在為病人治療之前徹底洗手並清洗醫療器械。

    當時，他提出這種理論倒不如去指責鬼魂或幽靈來得好。他遭到嘲笑，先後三次險些被撤銷從醫許可，最終不得不故意使自己感染，以證明他的觀點。在Semmelweis醫生去世之後，細菌致病的理論才得以發展起來，現在，他被認為是消毒理論和預防感染的先驅①。現在，所有醫生都知道這一點。他們不必再去重新發現醫療程式中的這個基本事實。他們甚至在非正式地會見一位新病人時也會洗手。

    在軟體開發中，人們有一種傳統的傾向，那就是期望每個開發人員自己去發現這樣的事情，犯所有人已經犯過的同樣錯誤，重新解決相同的問題，總之一切都要自己從頭幹。這實際上是“牛仔編碼者”文化的一部分，即開發人員總是爭強好勝，而不是互相支援②。在很多組織中這個問題愈加嚴重，因為他們傾向於把高階開發人員調往管理職位，導致那些初級開發人員不易從他們那裡學到東西。看起來人們並沒有認識到“會念經的和尚”的重要價值。

    問題並不僅僅在於我們知道什麼，或不知道什麼。我們必須學會分辨事情的輕重緩急——哪些事情必須現在就引起重視，哪些事情可以安全地忽略或過後再考慮。

    專業就像一個活的有機體。醫學已經存在數千年了，但沒有哪位醫生能活這麼久。今天的醫生可以從醫學這個有機體得到支援，他們可以從Simmelweis醫生這樣的先驅者們曾經的艱苦工作和犧牲中獲益，儘管Simmelweis醫生已經去世很久了。

誰說了算

    一般來說，一個人在去看醫生時不會說：“你知道，醫生，我想我需要做一個闌尾切除術。”你應該告訴醫生你的症狀，然後由醫生來建議適當的治療方法。

    在軟體開發中，我們沒有把自己當作專業人員，因此客戶也沒有把我們當作專業人員。專案的干係人往往設定時限，強行規定開發過程，並且干涉專案的進行。

    如果軟體開發是一個專業的話，這些就都將由我們自己決定，或者至少在很大程度上受我們的影響。我們將負責制定這些決策，而且可以非常肯定地告訴客戶他們會得到什麼，以及何時得到。但是，目前的情形就像是一個人到醫生那裡做手術，告訴醫生：“你有一個小時的時間，我要趕在11點前去打高爾夫球。”

    這需要思想上的轉變，做出改變的不僅是我們自己，還有客戶。這需要建立信任，改變客戶與開發人員之間關係的基本本質，並且通過提高成功率來證明我們的價值。

    雖然這是一個艱難的過程，但它必須發生。

    我相信軟體開發不僅僅應該被當作一個專業來從事，而且在21世紀的今天，它應該被當成一個最重要的專業來對待。

    原因何在？

    所有專業都要使用軟體，因此會受到軟體成本和質量的極大影響。當你坐飛機旅行時，實際上是坐在軟體上飛行，而且對軟體的依賴性越來越強。當醫生掃描病人的腹部，並盯著超聲波機器的螢幕看是否有腫瘤時，她需要依靠軟體來判斷如何為病人做診斷。當個人身份資訊被盜用時，也是由於別人的軟體在某個地方洩露了你的資訊。

    這至少在某種程度上又回到了規章和認證的問題上。有關我們這個專業應該適用什麼樣的規章和認證，我尚未形成一個明確的觀點，但我十分關心這個問題。在未來的若干年中，隨著軟體日益滲透到普通人日常生活的各個方面，軟體的失敗將越來越成為社會關心的一個問題。如果我們繼續使人們暴露在身份盜用、醫療和運輸事故、病毒、Y2K（或夏時制）等型別的bug的風險之下，那麼最終人們會另去尋找解決問題的辦法。

當然，他們將求助於政府。我並不想太強調這點，也不想成為一個杞人憂天者，但坦白地講，如果美國眾議院要來為專業軟體開發設定標準，我想我們不會有什麼好果子吃的。我們必須自己做這件事，而且我認為最好現在就開始做。有很多事情要做，我並不是強調所有事情都要在這裡做完（這應該是一個全社會都參與的草根活動）。但我希望本書能夠澄清一些關鍵問題，並起到拋磚引玉的作用。

獨特性

    讓我們來澄清這樣一件事：我並不是說軟體開發就像醫學、法律或任何其他專業一樣。醫學與法律也不一樣。醫生也不是木匠。

    專業具有獨一無二性。它們都已發展出獨特的、非常符合本身性質的流程。這些流程源自對專業性質的基本理解，而且是由自己專業的群體經過長時間逐步建立起來的。醫學之所以是現在這個樣子，是由於醫學專業人員在長期的專業歷史中所累積的經驗而形成的。

    軟體開發實踐中的一部分問題在於它在很大程度上是基於一個有缺陷的原則建立起來的，即它看上去不像是專業的軟體開發。這就是接下來的兩章要討論的問題。