《軟體工藝師：專業、務實、自豪》一導讀

那是20世紀90年代中期，我的職業生涯剛剛開始兩年，巴西聖保羅有家大型國際公司宣布要一次招納60名開發者。選拔過程分四個階段，共需數周時間。第一階段是三小時技術測試；第二階段是兩周的公司專有技術教育訓練，教育訓練結束後考試；第三階段是一整天團隊互動；第四階段是最終一輪面試。該公司在一家大報紙上刊登了這一消息，大約有900名開發者應聘。那時我正在一家小軟體公司上班，工作非常開心，但我覺得自己已經準備好幹一番大事。因為第一階段安排在周六，是以我決定去試試。不到300名開發者進入第二階段，我也在其中。我信心滿滿但略帶憂慮。接下來的選拔過程需要很多天，如果我要繼續參加剩下的三個階段，那就必須辭掉現在的工作。當時我經濟條件并不好，而且也無法指望家人資助。為了追求理想的工作而放棄現有的工作，是非常艱難的，何況那份工作還未必能夠被錄用。而且一旦找不到新工作，我也不知道怎麼維持生計。然而我還是辭職了。我必須去試一試——我就是想去那樣的公司上班，我就是想從事那份工作。

那年我21歲，雖說很年輕，但其實已經有好些年程式設計經驗了。我11歲開始寫代碼，19歲開始上班。問題在于，像這種年輕而又稍微有點經驗的人很容易驕傲。我自然也不例外。我就是一個傲氣的年輕開發者。我覺得自己比誰都強。我當時認為自己特别優秀，比學校裡的同學強，也比從前共事的大部分同僚厲害。

四個階段都結束後，公司宣布沒有招滿60名符合要求的員工。他們隻招了32個人，我就是其中之一。我當時真是興高采烈、志得意滿。公司的系統中有多個業務子產品，第一周上班，我分到了負責傳遞某個業務子產品的開發團隊裡。頭幾周時間，我在和負責其他業務子產品的開發者聊天時，聽他們提到了一個團隊，據說那是公司裡最好的團隊。那就是所謂的“架構”（architecture）團隊，他們負責系統核心，并且要提供所有的基礎代碼（infrastructure code）給各業務團隊使用。

架構團隊的主管是個了不起的家夥，除了做管理工作之外，他還是個出色的開發者。他是個大忙人，但總能擠出時間去寫代碼、以自己的身份送出代碼，并審校本團隊其他成員的代碼。我聽說那個團隊一直在做些有趣的事，而且代碼寫得超級棒。那正是我想去的地方。我想和最優秀的人在一起。

漫長的幾周過去了，我決定和架構團隊的經理談談，他就是我剛說的那個人。我既不知道該談些什麼，也不知道結果會怎樣。我能确信的事隻有一件：我沒什麼可失去的。最壞的結果就是他說他不想把我放到他們團隊裡。某天我看他一個人在咖啡間，于是哆哆嗦嗦地走了過去。我向他介紹自己：“你好，我是sandro。”他對我微笑，跟我握手，并且平靜而從容地說道：“我是namur。很高興認識你。”幾秒鐘尴尬過後，我緊張地說了一句：“我想加入你們團隊。”他稍微有點驚訝，但看上去很高興。我開始和他聊應聘的過程，聊自己為什麼要來這家公司，以及公司對我的要求等。他也問我有沒有參加業餘興趣項目，問我對什麼技術感興趣，以及是否在工作時間之外寫代碼，然後還說了其他一些事，我記不得了。聊了大概30分鐘之後，他就問我什麼時候可以開始過來上班。我愣住了。我根本沒想到他這麼快就會答應。我以為還要安排一次面談，再來一場正規面試什麼的。後來我才意識到，其實整個談話過程中，他都在判斷我對軟體開發的喜愛程度。他在分析我是不是那種認真負責的人。他并不擔心我目前的技術知識水準。我對namur說：“我去和現在的經理談談，希望能快點過來。”幾周之後，我就和新隊友坐在一起了。

第一天上班是個周一。namur早上跟我說，要布置一項任務給我。他描述了應用程式的某個部分，以及我需要完成的事項，然後說周五會過來看看我的成果。我太激動了。這正是展示自己能力的好機會！我要叫他看看我自己在團隊中的價值。于是，我一直到深夜才離開辦公室，隻睡了幾小時，周二一大早就爬起來上班，到周二下午兩點就把任務完成了。隻花不到一半時間就做完自己的第一份任務，這感覺妙極了。我一向都認為自己很棒，但這次，在這樣一個高水準的團隊裡，面對這樣一份從未參與過的代碼庫，我能把任務完成，那真是了不起！

我跑到namur辦公室，興奮地告訴他：“做好了。程式已經寫完，而且能夠運作。”他當時正在敲鍵盤，看到我之後停了下來，平靜地說：“寫出的程式能運作，隻是我對員工最起碼的要求。你告訴我某個程式已經寫完，那本身就意味着它要能正常運作才對。”這話給我潑了盆冷水。我臉上的笑意稍稍收斂了一下，不過我認為這也許隻是他的說話習慣而已。可能他今天不太順吧。我想他絕不至于故意講難聽話。“咱們坐下來看看你寫的代碼吧。”他繼續說着。我坐下看他從源碼控制系統裡擷取一份.pas檔案，我寫好的所有代碼都在這份檔案裡。他通過指令行，用一種黑綠相間的神奇編輯器打開了這份檔案。那是我頭一次看到vi。當時我們一般都是用delphi來開發的，delphi是一種非常流行的內建開發環境（integrated development environment，ide），功能特别強大。我看到有人用vi打開delphi檔案，覺得特别怪異（vi是一種unix文本編輯器）。“坐過來一點，咱們一起看代碼。”他說。我寫的代碼大概有兩百行。他把光标移到第一行，然後一行一行往下看。每五六行，他就停下來，跟我說下面這些話：“你知道配置設定記憶體和釋放記憶體的時候會發生什麼嗎？看看這裡，你在一個方法裡面配置設定記憶體，但卻在另一個方法裡面釋放。這可能會導緻記憶體洩漏。聽說過臨時耦合（temporal coupling）嗎？看看這塊代碼，你仔細想想就會發現，可以把它從8行精簡到2行。你知道在try/catch塊中放這麼多語句會出現什麼問題嗎？這個變量和方法的名字起得合适不合适？它們表示什麼意思？你是否想過，有些同僚可能需要修改這段代碼，但他們又不像你那樣，擁有足夠的資訊和明确的語境，他們怎麼了解這些名稱呢？他們在不了解這段代碼的情況下，又該如何維護呢？這個地方怎麼會出現寫死？你有沒有想過，現在把固定值寫在這裡，将來萬一要修改，那我們又要打開代碼、修改代碼、編譯代碼，而且要重新部署整個應用程式？檔案裡為什麼老是重複出現這幾行代碼？噢，還有這裡，這個方法怎麼這麼長呀！要是每個方法都寫這麼複雜的話，我們看代碼的時候還能不能了解它了？應該使它們短小精悍，而且要按照功能起個合适的名字。”他就這樣一直說下去……

然後，他在一個地方停了下來，開始盯着那幾行代碼。他在那上面花了幾分鐘，偶爾把光标移到前一屏或後一屏看看。20世紀90年代那陣，如果某個開發者能寫出别人看不懂的代碼，那大家就會覺得這個人很強，他們會說：“這個人肯定特别厲害，寫出來的代碼我們都看不懂喔。”我在那份源檔案裡也寫了一些晦澀難懂的代碼，用來炫耀自己很聰明。等namur看明白那些代碼的時候，我在想，他最後總該鼓勵我一下吧？但是他卻冷冰冰地說：“你知不知道這麼寫代碼很不好？我們在做一個非常大的系統，有很多團隊和開發者都要在同一份代碼庫上面工作。要是每個人都這麼炫耀的話，這代碼了解起來該有多困難？不要說有幾百萬行代碼，就算隻有幾千行，這樣寫也不行。”第二盆冷水又潑了下來。

我寫的代碼隻有兩百行，但針對這兩百行代碼，我卻沒辦法回答他的任何問題，他指出那些缺點時，我也想不到該怎麼答複才好。他就這樣一行一行看着代碼，批評我的寫法，然後跟我說應該怎樣寫才會更好。等他看完整份檔案之後，我已經十分羞愧苦惱了，但他依然淡淡地對我說：“你明白我剛說的那些了嗎？你覺得我的建議對不對？”他說話時那種口氣，就好像寫代碼的這個人不是我，而是另一個不在場的陌生人一樣。我什麼都沒說，隻是點點頭。他又問：“你現在覺得自己能把這份代碼寫得更好一些嗎？”我沒看他，隻是點點頭。他還接着問：“你覺得自己以後寫代碼的時候能不能做到我們剛說的那些？”我還是隻點了點頭。于是，他按了幾個鍵，把我寫好的整份代碼檔案全删了，然後說：“嗯，那就好。還有三天時間呢，重寫吧。”

我又愣住了。我不知該怎麼回答。站定之後，我緩步走向門口，一句話也沒說。“sandro，”快走到門口時他叫住我，“方式與結果一樣重要。”說完之後，他又回過身，對着那個怪異的綠色編輯器開始打字。

我很沮喪。實際上，我特别憤怒。離開他辦公室後，我直接下樓，走出了公司。當時我心想：他以為他是誰呀，居然用這種口氣跟我說話，混蛋！我才不給這種人幹活呢。真是受夠了！我不想留在這家公司了！辭職！抽了幾根煙後，我冷靜了一點，開始回想剛才的事。namur畢竟花了一個多小時來看我的代碼，而且還跟我解釋了怎樣才能寫得更好。在我偶爾表達自己觀點的時候，他也能傾聽，并且會認真地指出我的錯誤，或者告訴我還有另一些更好的寫法。我發現，自打開始程式設計，這是頭一次有人肯花工夫告訴我怎麼樣才能寫出好的代碼。另外，他水準确實比我高很多，而且經驗也遠比我豐富，他是真心希望别人能把代碼寫好的那種人。我想，我發現了一個追求優秀軟體和高品質代碼的人。這樣一個人會花時間來指導我，而且，更重要的是，我找到了自己的第一位導師。

幾根煙過後，我重新振作起來，跟變了個人似的。那天我終于明白自己并不如想象中那般優秀；我明白了應該如何保持謙虛的态度；明白了我還有很多東西要學；明白了隻把事情做完是不夠的，尤其是身處團隊之中；明白了怎樣做才能受到同僚與客戶尊重，而不是留下一堆爛代碼不管；更明白了一名真正優秀的專業人士一定會在乎自己的作品。

關于本書

數十年間，衆多軟體開發方式（methodology）湧現，可是軟體項目依然會失敗。失敗的原因很多，但有幾個問題不容忽視：管理者隻把軟體開發當成一條生産線；公司不知道怎麼管理軟體項目，不知道怎麼招聘優秀開發者；很多開發者仍然不夠專業、不夠積極，他們向雇主和客戶提供非常糟糕的服務。有了靈活軟體開發（agile）這種方式之後，軟體行業确實出現了巨大進步，但軟體項目的失敗率還是很高。這些項目為什麼依舊做不好呢？為什麼無法順利完成軟體項目呢？我們到底缺少什麼？

盡管“軟體工藝”這個詞十幾年前就出現了，但直到最近它才成為一種可靠的解決方案，能夠用來應對軟體行業時下面臨的許多問題。

軟體工藝為開發者和軟體公司提供了一套獨特的理念。盡管它并不是一種軟體開發方式，但卻強烈建議我們采用某些技術實踐手段及指導原則，這些手段和原則基本上都在極限程式設計（extreme programming）中做了界定。通過與靈活（agile）和精益（lean）原則緊密結合，軟體工藝可以大幅提升軟體行業的水準。它關注的重點是專業精神、高超技術，以及良好的客戶滿意度。而其中一個重要方面就是轉變态度：不要再把軟體開發者看成生産線上的勞工，也不要再把管理軟體項目當成開工廠。

如何才能變成更好的開發者？如何才能傳遞更好的軟體項目？本書将會講述真實案例，給開發者和軟體公司提出實用的建議，直接參與軟體項目的每位開發者和專業人士都适合閱讀本書。

目　　錄

第一部分　理念及态度

第4章　軟體工藝師的态度

4.1　你的事業由誰掌控

4.2　與時俱進

4.2.1　博覽群書

4.2.2　閱讀并撰寫部落格

4.2.3　關注技術網站

4.3　尋找業界高手

4.4　反複練習

4.4.1　kata

4.4.2　興趣項目

4.4.3　開源項目

4.4.4　結對程式設計

4.5　參與社交活動

4.6　主動發現問題

4.7　兼顧工作與生活

4.7.1　擠出空閑時間

4.7.2　用“番茄工作法”集中注意力

4.7.3　處理好工作與生活之間的關系

4.8　小結

第5章　争強好勝、滿腔熱情與專業精神

5.1　學會拒絕

5.1.1　大敗局

5.1.2　從這次失敗中得到的教訓

5.1.3　更加專業地工作

5.2　提出解決辦法

5.3　開明的項目經理

5.4　小結

第6章　什麼是可行的軟體

6.1　隻開發出可行的軟體是不夠的

6.2　軟體維護

6.3　潛在的危險

6.3.1　編寫高品質的代碼

6.3.2　要雇用軟體工藝師，而不是平庸的開發者

6.4　錯誤的時間觀念

6.4.1　技術債務的故事

6.4.2　過于忙碌的團隊

6.4.3　單元測試任務卡

6.4.4　合理運用時間

6.5　遺留代碼

6.5.1　轉變态度

6.5.2　既要享受工作，也要令客戶滿意

6.6　小結

第7章　技術實踐

7.1　不僅要做正确的事情，而且要把事情做好

7.2　軟體公司的具體情況

7.3　極限程式設計的曆史

7.4　極限程式設計的做法及其價值

7.5　為自己的決策負責

7.6　注重實效

7.7　小結

第8章　漫漫職場路

8.1　巴西少年成長記

8.2　專注與決心

8.3　把工作當成投資

8.4　自主、精通與目标

8.5　在公司内謀求發展與追求事業成功之間的關系

8.6　小結

第二部分　全 面 轉 變

第9章　招納人才

9.1　普通的職位描述

9.2　因過于忙碌而草率地招聘

9.3　最好别在招聘啟事上面寫職位描述資訊

9.3.1　如果一定要寫職位描述，如何寫才好

9.3.2　這不僅僅是一份工作

9.4　推薦工作

9.5　參與社團活動

9.6　确定有效的篩選标準

9.7　儲備式招聘

9.8　小結

第10章　面試軟體工藝師

10.1　把面試當成商業談判

10.2　如何判斷對方是不是良好的合作夥伴

10.2.1　用人公司對良好合作夥伴的了解

10.2.2　開發者對良好合作夥伴的了解

10.3　有效的面試

10.3.1　在面試中關注重點

10.3.2　用思維圖促進談話效果

10.3.3　在面試過程中結對程式設計

10.3.4　請根據公司的實際要求來設計面試

10.4　大膽錄用有潛力的開發者

10.5　如何為現有團隊招募新成員；如何招募新團隊

10.6　面談之前先通過代碼練習來篩選開發者

10.7　每個人都應該學會面試

10.8　必須由開發者來面試開發者

10.9　小結

第11章　面試中的禁忌

11.1　不要自作聰明

11.2　不要出腦筋急轉彎問題

11.3　不要問連自己都不知道答案的問題

11.4　不要看不起開發者

11.5　不要阻止開發者上網

11.6　不要在紙上寫代碼

11.7　不要用算法來面試開發者

11.8　不要安排電話面試

11.9　小結

第12章　團隊士氣低落的害處

12.1　公司向靈活轉型之後所表現出的問題：士氣低落

12.2　雇用“朝九晚五”式開發者的代價

12.3　缺乏工作動力會阻礙公司的變革

12.4　請軟體工藝師來提升團隊的工作熱情

12.5　小結

第13章　營造學習氣氛

13.1　錯誤的變革動機

13.2　營造一種學習文化

13.2.1　舉辦讀書會

13.2.2　舉行午餐研讨會

13.2.3　舉行小組讨論

13.2.4　在一個疊代周期内互換項目

13.2.5　小組代碼審校

13.2.6　舉行程式設計實驗

13.2.7　在公司内部組織實踐社團

13.2.8　鼓勵大家做興趣項目

13.2.9　參與公司外的技術社團

13.3　其他人不想參與時該怎麼辦

13.3.1　自己做個榜樣

13.3.2　關注那些樂于改變的人

13.3.3　不要強迫他人參與

13.3.4　不要試着改變每個人

13.3.5　避免出現大家都借故不參加活動的情況

13.3.6　不必征得老闆同意

13.3.7　不要化簡為繁

13.3.8　建立有規律的聚會制度

13.4　小結

第14章　推動技術變革

14.1　确定自己所面對的質疑者是何類型

14.2　為推進技術變革做好準備

14.3　從何處入手

14.3.1　建立信任

14.3.2　以身作則

14.3.3　逐個解決問題

14.3.4　疊代、回顧、調整

14.4　恐懼與無能

14.5　如何說服主管

14.6　如何說服團隊采用tdd

14.7　面對質疑

14.7.1　如何面對“象牙塔裡的架構師”

14.7.2　如何面對抱怨公司的人

14.8　你真的要在乎這麼多嗎

14.9　小結

第15章　務實的軟體工藝

15.1　大家總是想要高品質的軟體

15.2　打破“開發高品質的軟體昂貴而耗時”這一迷思

15.3　重構

15.4　軟體開發的方式不止一種

15.5　幫助業務人員

15.6　軟體項目并不是圍着我們轉的

15.7　優秀開發者與平庸開發者之間的差別

15.8　簡潔設計四原則

15.8.1　設計模式

15.8.2　從重構到模式

15.9　軟體工藝與務實态度

15.10　總結 189

第16章　軟體工藝師的職業進化之路

16.1　軟體工藝師的品格

16.2　職業發展

16.3　道路與裡程碑

16.3.1　選好職業發展過程中的每一份工作

16.3.2　不知道接下來的發展方向怎麼辦

16.4　接觸各種類型的軟體開發工作

16.5　使命感