68
《軟件工藝師：專業、務實、自豪》一導讀
前 言
那是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，網址是：https://www.meetup.com/london-software-craftsmanship），而Namur的那句話——“方式與結果一樣重要”（how it is done is as important as getting it done），成了我建立網站時第一批寫上去的文字。後來我給LSCC定製了一些T恤衫，這句話也印在上麵。這句話不僅使我成為一名更優秀的開發者，而且也把我變成了一個更好的人。
關於本書
數十年間，眾多軟件開發方式（methodology）湧現，可是軟件項目依然會失敗。失敗的原因很多，但有幾個問題不容忽視：管理者隻把軟件開發當成一條生產線；公司不知道怎麼管理軟件項目，不知道怎麼招聘優秀開發者；很多開發者仍然不夠專業、不夠積極，他們向雇主和客戶提供非常糟糕的服務。有了敏捷軟件開發（Agile）這種方式之後，軟件行業確實出現了巨大進步，但軟件項目的失敗率還是很高。這些項目為什麼依舊做不好呢？為什麼無法順利完成軟件項目呢？我們到底缺少什麼？
盡管“軟件工藝”這個詞十幾年前就出現了，但直到最近它才成為一種可靠的解決方案，能夠用來應對軟件行業時下麵臨的許多問題。
軟件工藝為開發者和軟件公司提供了一套獨特的理念。盡管它並不是一種軟件開發方式，但卻強烈建議我們采用某些技術實踐手段及指導原則，這些手段和原則基本上都在極限編程（Extreme Programming）中做了界定。通過與敏捷（Agile）和精益（Lean）原則緊密結合，軟件工藝可以大幅提升軟件行業的水平。它關注的重點是專業精神、高超技術，以及良好的客戶滿意度。而其中一個重要方麵就是轉變態度：不要再把軟件開發者看成生產線上的工人，也不要再把管理軟件項目當成開工廠。
如何才能變成更好的開發者？如何才能交付更好的軟件項目？本書將會講述真實案例，給開發者和軟件公司提出實用的建議，直接參與軟件項目的每位開發者和專業人士都適合閱讀本書。
目 錄
第一部分 理念及態度
第1章 21世紀的軟件開發
1.1 何謂資深開發者
1.2 新的挑戰
第2章 敏捷軟件開發
2.1 麵向流程的敏捷軟件開發原則
2.2 麵向技術的敏捷軟件開發原則
2.3 何謂敏捷
2.3.1 轉變開發方式
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 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 使命感
最後更新：2017-06-22 15:01:51