譯者序

序

前言

致謝

作者簡介

部分理念及態度

第1章21世紀的軟件開發

  1.1何謂資深開發者

  1.2新的挑戰

第2章敏捷軟件開發

  2.1面向流程的敏捷軟件開發原則

  2.2面向技術的敏捷軟件開發原則

  2.3何謂敏捷

    2.3.1轉變開發方式

    2.3.2擴大參與範圍

    2.3.3豐富職業技能

  2.4《敏捷軟件開發宣言》

  2.5由傳統開發方式向敏捷轉型

  2.6因轉型不佳而表現出的問題

    2.6.1轉型不徹底

    2.6.2局部轉型的積極意義

  2.7敏捷軟件開發與軟件工藝的關繫

  2.8小結

第3章軟件工藝

  3.1更恰當的比喻

  3.2維基百科對軟件工藝的定義

  3.3筆者個人所推崇的定義

  3.4更為簡潔的定義

  3.5不要拘泥於定義

  3.6軟件開發是手藝、生意、工程、科學，還是藝術

  3.7軟件工藝的歷史

    3.7.1軟件工藝峰會

    3.7.2軟件工藝概念走向全球

    3.7.3軟件工藝師交換計劃

    3.7.4軟件工藝社團

    3.7.5《軟件工藝宣言》的制定過程

    3.7.6《軟件工藝宣言》及講解

  3.8小結

第4章軟件工藝師的態度

  4.1你的事業由誰掌控

  4.2與時俱進

    4.2.1博覽群書

    4.2.2閱讀並撰寫博客

    4.2.3關注技術網站

  4.3尋找業界高手

  4.4反復練習

    4.4.1

    4.4.2興趣項目

  ……

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

第6章什麼是可行的軟件

第7章技術實踐

第8章漫漫職場路

第二部分全面轉變

第9章招納人纔

第10章面試軟件工藝師

第11章面試中的禁忌

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

第13章營造學習氣氛

第14章推動技術變革

第15章務實的軟件工藝

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

附錄進一步澄清對軟件工藝的各種誤解

前 言

那是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畢竟花了一個多小時來看我的代碼，而且還跟我解釋了怎樣纔能寫得更好。在我偶爾表達自己觀點的時候，他也能傾聽，並且會認真地指出我的錯誤，或者告訴我還有另一些更好的寫法。我發現，自打開始編程，這是頭一次有人肯花工夫告訴我怎麼樣纔能寫出好的代碼。另外，他水平確實比我高很多，而且經驗也遠比我豐富，他是真心希望別人能把代碼寫好的那種人。我想，我發現了一個追求優秀軟件和高質量代碼的人。這樣一個人會花時間來指導我，而且，更重要的是，我找到了自己的**位導師。

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

我和導師Namur及其他一些優秀開發者共事了兩年半的時間。這段經歷不僅使我變得更加專業，而且使我變得更會做人。雖然當時並沒有提及“軟件工藝”這個詞，但十年之後我發現，我**次接觸這個概念正是在那個時候。我從他們身上學到了很多。從技術角度來看，那是一段有益的經歷，但*重要的並不是技術本身，而是我在那段時間裡從主管和同事那裡學到的對待工作的態度。**次審校完代碼時，Namur對我說的那句話徹底改變了我。十年後，我成立了倫敦軟件工藝社團（London Software Craftsmanship Community，LSCC，網址是：），而Namur的那句話——“方式與結果一樣重要”（how it is done is as important as getting it done），成了我建立網站時**批寫上去的文字。後來我給LSCC定制了一些T恤衫，這句話也印在上面。這句話不僅使我成為一名更優秀的開發者，而且也把我變成了一個更好的人。

關於本書

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

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

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

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

Acknowledgements?致 謝

我的職業生涯是一段精彩旅程，從巴西小鎮到歐洲大城。我在大西洋兩岸的數家公司就職過，遇到了很多高手，他們以各種方式幫助我，使我更會做人，也更會工作。

首先我要感謝Maria Cecilia Capelache教授。當我告訴她，自己可能要因為經濟問題而輟學時，她立刻給我提供了一份工作，使我可以繼續完成學業。直到今天，我依然覺得，她給我那份工作主要是為了幫我，而不是那個團隊當時真的需要多加一名開發者。她告訴我學校裡教的那些知識和現實中的軟件開發有何不同。假如我當時從大學退學，今天可能就不會寫出這本書了。

然後我遇到了Luiz Fernando Ferreira，他是那家小軟件公司的一名雇主，他給了我第二份工作。雖說我是他們的首位雇員，但公司並沒有把我隻當成員工對待。**天上班，我就感覺自己在和一位老友共事。今天我倆依然是朋友，無論身處順境還是逆境，他都非常坦誠，在我需要提升自己的時候，他也給了我莫大幫助，這些我永遠心存感激。

去跨國大企業上班，並得到良師指導，這改變了我的職業生涯。真的很感謝Eduardo Namur，他告訴我做事的方法與做事的結果一樣重要，他把公司變得像大家庭一般融洽，他鼓勵我努力前行，並使我意識到軟件工藝的種種原則，那時還沒出現軟件工藝這個詞呢！

Alexandre Ehrenberger是我從前的經理，後來成了我的好朋友，他經常激勵我，在我決定搬去倫敦時大力支持我。他在加拿大住了六年，並告訴我怎樣做纔能實現倫敦之夢。非常感謝他的友誼，感謝他給我的建議、鼓勵和支持，這些都使我明白，努力工作會令夢想成真。

要去倫敦，必須做兩件事。**是學Java語言，為此，我努力研究Java，並找了份與Java有關的工作。還有一件事就是學好英語。我要感謝可愛的Ana Maria Netuzzi女士，謝謝她這些年來專門給我補習英語，她是我的朋友，而且有時也是我的心理輔導師，聽我訴說心事並給我寶貴建議。

在英國一家小軟件公司稍微工作了一段時間後，我加入了一家創業公司。那裡有很多優秀的開發者，那是我第二次感覺到有些人真的很在乎他們手頭的工作。他們使我提升了自己的技術水平，但更重要的是，他們成了我在英國的**批朋友。他們不僅令我變成了更好的開發者，而且令我融入了英國社會。感謝Chris Webb、Greg Cawthorn、David Parry、Russell Webb、Simon Kirk和James Kavanagh。

加入Valtech公司是我職業生涯的一大進步。在那裡，我初次接觸了敏捷軟件開發和極限編程，那是迄今為止我學到知識*多的地方。雖然我無法列出遇到的每一位優秀同事，但還是要特別提到其中幾位。感謝我的良師益友Akbar Zamir。我從他身上學到了許多，*重要的就是要開拓思維，接受新事物。他令我明白自己還有很多事情不懂。Akbar說服我嘗試測試驅動開發。他也向我介紹了領域驅動設計（Domain-Driven Design，DDD），並且告訴我許多敏捷軟件開發和極限編程的知識，此外還教我如何處理人際關繫、如何保持務實作風和專業精神。多謝，Akbar，我從你這裡學到了很多。Valtech公司還有幾位同事也極大地影響了我的職業生涯。他們是David Draper、Kevin Harkin、Andrew Rendell和James Bowman。感謝你們提供的大力指導和幫助。

在UBS公司上班時，我頭一次真正接觸了大型企業級繫統，它迫使我重新考量自己對軟件開發的看法。我在那裡同一個優秀的團隊一起工作，感到非常愉快。他們使我能夠以不同的角度來觀察事物。在UBS公司工作時發生的一件妙事，就是能和Mashooq Badar搭檔（我們在Valtech公司時就是同事，後來我開辦Codurance公司，他依然是我的搭檔），他是一名非常優秀的開發者，也是我的摯友。Mash使我有機會加入UBS公司。他也把Balint Pato帶進了公司的一個項目裡，使得我們之間能夠緊密協作。Mash和Balint同我討論了許多事情，他們的熱情、上進心與專業精神都鼓舞了我，讓我學會了很多東西，我要謝謝這兩位真正的軟件大師。Portia Tung是我在UBS公司遇到的另一位優秀同事，她也許是我見過*好的敏捷教練。她的熱情很有感染力，給我們打造了有歸屬感的工作環境，她積極地與我們分享她的深刻見解，告訴我們怎樣使大型機構變得更加靈活，這使我能夠在UBS公司把工作做得更好。Portia，謝謝你與我為友，謝謝你告訴我怎樣把大家凝聚起來。感謝Robert Taylor和Alexander Kikhtenko（也就是Sasha，他的綽號是“The Machine”）這兩位傑出的軟件工程師。和你們在一起工作，特別開心。

我要感謝David Green的地方實在太多了。他是做軟件的高手，是我的朋友，也是個特別聰明的開發者。我總是記得，晚上經常和他在酒館裡討論項目、討論編程技巧，討論怎樣纔能把軟件開發做得更好。我從David身上學到了很多。David和我一起創立了倫敦軟件工藝社團（LSCC），若沒有他，社團恐怕持續不到今天。

2013年10月，我和Mashooq Badar一起創辦了Codurance，這是一家咨詢公司，它以軟件工藝的原則和理念為基石。Codurance公司使我們的職業生涯更上一層樓。這次總算可以按照自己的想法來運作一家公司了。而Samir Talwar的到來則使得這段時光更為精彩。Samir是我們招募的首位軟件工程師，這位朋友本領極強。Codurance公司及LSCC今天的成功是與他分不開的。

*後衷心感謝LSCC中每一位熱情的開發者。正因為你們願意花費個人時間來與大家分享知識，所以我纔能在這麼短的時間內學到這麼多。誠摯感謝Gon?alo Silva、Samir Talwar、Tom Brand、Tom Westmacott、Emanuele Blanco、Carlos Fernandez Garcia及Chris Jeffery，你們是LSCC傑出的組織者。LSCC變得這麼棒，多虧了你們。

談到成書過程，我要感謝Micah Martin與Tyler Jennings，他們提供了與軟件工藝的歷史有關的知識。感謝Kevlin Henney給出的好建議，這優化了本書的結構，感謝他勸我把原來寫好的第1章刪掉，並重新寫一遍。感謝Gianfranco Alongi與Mani Sarkar校對本書。我要特別向Samir Talwar和Andrew Parker致意，他們找到了很多語法錯誤和筆誤，而且為提升本書質量提供了良好建議。還有許多朋友也對本書提出了建議並指出了拼寫錯誤，在此謹表謝意。