開發抽象層 The Development Abstraction Layer

作者:周思博 (Joel Spolsky)
APRIL 11, 2006
屬於 Joel on Software, https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-layer-2/

城裡來了個年輕人。他外表迷人,口袋裡也有些錢,女人們都樂意與他交談。

對於自己的過去他並不多談,但誰都看得出來他在大公司蹉跎了多年的青春。

年輕人的個性和善又外向,充滿了信心卻又不流於傲慢。也因此,他很快就開始在當地程式員聚會中接了些小專案來做。然而對於這些保單資料庫、銷售女性配件的網頁、財務計算程式之類的小專案,他很快就興趣缺缺了。

在無聊工作一年以後,他終於存到了一筆一年份的生活費。與愛犬小亞商量後,他就在自己雜貨店樓上灑滿陽光的租賃公寓裡架了一台電腦,並安裝了一些精心挑選的程式開發工具。

他一一打電話告訴他的朋友們,如果他接下來的幾個月失聯的話,便是正埋首於工作中,請大家不要擔心。

一切就緒後,他坐下來開始打造他心目中完美的程式。

他最後創造出來的程式是多麼地迷人啊。完美無瑕、充滿藝術氣息、優雅,而且一個臭蟲都沒有。由於使用者介面也完全符合人們的思考模式,他在當地程式員聚會中為同儕展示時,甚至沒有人注意到有使用者介面的存在。這是一個相當出色的傑作。

受到同儕所激勵,他開始設立公司並接受訂單。

雖然他並不懷著不切實際的期望,但一個月後他的銀行帳戶依然空虛。到目前為止他只接了三份訂單:一份來自母親、一份來自當地程式員聚會的匿名贊助,還有一份是他自己測試用的訂單。

第二個月過後,也沒有新增的訂單。

這個結果令他又驚訝又沮喪。他之前工作的大公司每次發表的新產品都沒什麼特別的。但即使產品不優雅也不漂亮,銷售量依然大好。他參與的其中一個甚至還相當熱賣。

又過了幾個月,他的經濟狀況開始顯得困窘。他的愛犬用哀傷的眼神望著主人,雖然不曉得到底發生了什麼事,但也知道主人的臉愈來愈憔悴了。年輕人甚至連約朋友出去,或是出門補充生活必需品及洗澡都顯得興趣缺缺。

在某個星期二早上,樓下的雜貨店開始不讓他繼續賒帳,城裡的銀行也很久不接他電話了。

他的老東家對他的離職並不懷恨在心。相反地,他們認同他的才華,也以更高薪找他回去工作。很快地,年輕人恢復了往日的光彩。他買了些新衣服,也找回失去已久的自信心。但他內心深處某些東西卻已不復見,那就是從前眼神裡的光芒。他原本期望能主宰自己命運的希望已幻滅了。

SCal2.png

他為什麼失敗了呢?他相信他早就知道了答案,「就是『行銷』!」他說。就像很多的年輕技術人員一樣,他總是這樣說︰「微軟的產品很糟,但是他們很會行銷。」

在軟體開發者的口中,「行銷」這個詞就代表了所有做生意的事︰創造軟體並且把軟體賣出去,正是軟體開發者所不懂的那些事。

其實,「行銷」這個詞彙的意思真的不是這回事。其實,微軟的行銷真的很糟。你能夠想像,那些用恐龍人偶當主角的廣告,真能讓人想掏錢買微軟的 Office 嗎?

軟體是一種對話 -- 軟體開發者與使用者之間的對話。但是,想讓這種對話發生,還需要很多軟體開發以外的事。沒錯,它需要行銷,但還需要銷售、公關,還有間辦公室、網路、基礎設備、辦公室的冷氣,還有客戶服務、會計,還有一大堆其他的支援性工作。

但是軟體開發者在幹什麼呢?他們在設計程式寫程式、他們編排畫面、他們除錯、他們整合、他們還會把程式碼給簽入到原始碼的控制系統中。

程式員的工作層次(比方說,Emacs)實在太過於抽象了,抽象到做不了生意。在抽象層工作的軟體開發者,還需要一個實作層 -- 一個能將程式碼轉換成產品的組織。桃莉巴頓(Dolly Parton)是在”唱好歌”那一個層次的,她也需要一個龐大的實作層,來幫她灌唱片、訂演唱會場地、賣票、音效、宣傳、收版稅。

SCal3.png

任何成功的軟體公司都會包括薄薄一層的開發者,這些開發者散佈在巨大管理組織抽象層之上建立軟體。

這個抽象層存在的目的,只是為了建立一種假象,讓大家覺得一個程式員的日常活動(程式碼的設計及撰寫,程式碼的簽入、除錯等等),就是建立軟體產品並將之引入市場的一切。這一點讓我得出本文最關鍵的重點:

身為軟體團隊經理,你的第一要務是建立開發抽象層。

大多數軟體經理新人都未察覺這個重點。他們只會一直想由好萊塢電影學到的傳統命令式管理模式。

在命令式的作法中,經理/團隊領隊會找出公司的目標,然後對副官下達適當命令把公司往讓方向移動。副官接下來會細分工作再命令下屬執行。這個過程會沿著組織圖往下重複進行,直到最後某個在最底層的人實際做事為止。在這種模式之下,程式員就是機器中的一根齒輪牙:一個執行管理階層命令中某一部份的打字員。

某些企業實際上就是用這種方式運作。當你遇到這種公司一定都能分辨,因為和你說話的人都會做某些沒大腦且惹人生氣的事情,他們自己知道問題可能甚至還會介意,不過卻無法可施。就是這種航空公司,會在客戶想更改不可退費機票趕回家處理急事時拒絕,結果失去一個時常坐飛機的重量級顧客。就是這種網際網路供應商斷線時間超過正常營運的時間,而且在你停用後還一直跟你收錢收錢收錢;而當你打電話去抱怨時,卻得打付費電話花一個小時等候轉接,結果還是拒絕退費,直接你開始寫網誌罵他們有多爛才作罷。就是這種底特律的汽車公司,長久以來早已忘記要如何設計出大家想買的車子,只會一直改變行銷策略,好像我們不買他們的爛車只是因為折扣打得不夠。

SCal1.png

夠了。

把它忘了吧。命令式的階層管理系統已經被試過了,在 1920 年代與推著車的小販競爭時,這種作法有一陣子似乎行得通,不過對 21 世紀來說並不夠好。軟體公司需要使用不同的模式。

對一家軟體公司而言,管理的第一要務就是替程式員建立那樣的抽象層。

如果某個程式員正為椅子壞掉而操心,或是因為等 Dell 送新電腦來閒置,表示這個抽象層已經有了裂縫。

把你的開發抽象層想像成一艘具備超級馬力的美麗大遊艇。遊艇的維護無懈可擊。美食準時送上。包廂每天有兩次整理服務。導航地圖隨時更新。全球定位系統和雷達從不出問題,就算壞了艙內也有備份。而在艦橋上則是只需要考慮速度方向以及午餐吃鮪魚還是鮭魚的程式員。同時有一大隊身著漿硬白制服的專業人員在甲板下悄悄活動,維持所有事情的運作、填滿油槽、刮除藤壼、熨平午餐餐巾。這個支援團隊知道要做什麼,不過全都聽從臭屁老領隊(salty old fart)的指示。後者只要往某個方向輕輕點頭,整隊人就會完全協調演出,讓程式員能把遊艇的細節全部抽象掉,只要管速度和方向,以及午餐要吃些什麼。

最需要為建立程式員的抽象層負責的就是軟體公司的管理階層。我們建造遊艇,我們服務遊艇,我們就是遊艇本身,不過我們不駕駛遊艇。我們做的每件事都是要為程式員提供一個無縫隙的抽象層,讓他們能創造出偉大的程式,再讓那些程式抵達能因而獲益的客戶手中。

程式員需要 Subversion 儲存庫。建立一個 Subversion 儲存庫意味著你需要一個網路和一台伺服器,必須去採購、安裝、備份,還要配置不斷電系統;伺服器會產生很多熱,表示你得準備一個有額外空調的房間去放;而空調得連接到大樓外,表示大樓外牆外面要裝一個 80 磅的風扇;安裝這東西會讓屋主緊張,所以他們得帶自己的工程師來,協調要在哪裡安置空調設備(決策結果:要裝在往上到 18 樓的外牆上,可能是最不方便的位置),而屋主也會拉律師進來,因為我們得付出許多才獲淮進行;然後當空調安裝人員出現了,還帶著有如芭比玩具組的吊索機具,讓我們的建築工頭緊張起來,不肯讓他們穿著半吋粉紅塑膠製的美泰兒(Mattel,譯註:著名玩具商)繫具爬出 18 樓窗外,於是有人得再把包商找來,搞清楚他們為什麼在施工 12 週後,會突然發現得為這該死空調再次修改合約,而且這東西早在耶誕節前就知道要裝但是剛剛才弄清楚。而這件事即使只讓你的程式員花一分鐘去想都嫌太多。

就你的團隊中的軟體開發者而言,這一切都必須被抽象化成只要在命令列鍵入 svn commit。

這就是要有管理階層的原因。

管理階層就是為了那些沒有公司能避免的事,不過如果讓你的程式員為此而操心,那麼管理階層就算失敗了。這就像如果百萬富翁船主得下去引擎室建造引擎,這台一百英呎長的遊艇也算失敗了。

有些典型的軟體公司是由前軟體業務開始,在這種公司裡銷量就是一切,所有人都是為了增加銷售量而存在的。市場上的這種公司可以辨別得出來,由於他們會製作軟體的 1.0 版(不知怎麼出來的),然後就完全沒興趣開發新軟體了。他們的開發團隊不是已經被餓死就是根本不存在,由於沒有人想到要去製造 2.0 版...管理階層懂的事就只有增加銷量。

在另一個極端是由前程式員所建立的典型軟體公司。這些公司比較難以發現,由於在大部份情況下他們都會安靜地堅持,在某個無人能發現的閣樓上磨亮他們的程式碼,於是他們就在「大 Ruby 重寫風潮」(Great Ruby Rewrite)後靜靜地被人遺忘,而他們足以改變世界,能重整程式碼的程式結果也無法被世人欣賞。(譯註:作者指 Ruby 太流行,一堆人用 Ruby 重寫程式而不重整程式,所以能重整程式碼的重要工具就被人忽略了)

當一家公司是由程式員驅動,在組織上讓程式員坐上駕駛座,同時卻有優異的抽象層能在甲板下完成所有把程式碼轉成產品的苦工。前面這兩種公司都會輕易地被這樣的公司消滅。

要讓一位程式員發揮最大的生產力,必須搭配一間安靜的個人辦公室、一台強大的電腦、無限制的飲料,華氏 68 到 72 度的室溫、螢幕上沒有反光、一張極舒適而不會感覺到的椅子、一位替他們帶來信件和訂購的書籍手冊的管理者,一位讓網際網路讓氧氣般隨時可用的系統管理者、一位能找出他們自己看不到的臭蟲的測試人員、一位讓他們的畫面美麗悅目的繪圖設計師、一組讓大眾想要他們產品的行銷團隊、一組確保大眾能拿到這些產品的業務團體、幾位協助客戶使用產品,並讓程式員瞭解導致客服電話的問題,極具耐心的技術支援聖人、以及其他十幾位支援及行政人員,而這些在一家典型的公司裡總共會佔用八成的薪資支出。羅馬軍隊中每位士兵配置四名僕人的比例並非巧合。這並不是墮落。現代軍隊的比例可能高達 7:1。(今天 Pradeep Singh 教了我一些事:如果在你的人員中程式員只佔兩成,而把程式工作外包到印度可以節省五成的薪水,那麼省下的一成支出究竟可以帶來多少的競爭優勢呢?)

管理階層的首要任務,就是創造出軟體公司能靠撰寫程式碼運轉的假象,由於這就是程式員所做的事。雖然擁有同時擅長銷售、繪圖設計、系統管理以及烹飪的程式員是很棒沒錯,但是並不切實際。就像教一隻豬唱歌一樣,既浪費你的時間又會惹惱豬。

微軟在建立這種抽象層上做得非常好,以致於微軟離職員工開創公司時非常辛苦。他們就是無法相信有多少事在甲板下進行,也不知道要如何去重現。

SCal4.png

沒有人期望桃莉巴頓知道如何接上麥克風。她背後有一個無法想像,由經理人、音樂家、錄音技師、唱片公司、巡迴演出經紀人、美髮師、宣傳人員組成的基礎結構,這全部的一切只是要在她唱歌時建立那種抽象性,好像數百萬人會聆聽只是因為是她在唱歌。這所有讓桃莉巴頓得以實現的支援人員和管理階層所能做的最佳工作,就是提供最完美的抽象:那種桃莉巴頓為我們而唱的完美假象。這就是她的歌。當你用你的 iPod 聆聽她的歌,其實是有個巨大的基礎結構讓這件事實現,不過這個基礎結構所能完成最棒的事就是完全消失。只剩下桃莉巴頓獨自對我們唱歌這個完美的抽象意念。

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