軟體開發之韻

《軟體開發之韻》是2010年5月電子工業出版社出版的圖書，作者是楊艷 、丁大江 、倪禕昭、 王天驕。該書是一本關於推薦、推廣、推崇敏捷開發的軟體方法學教材。

基本介紹

• 書名：軟體開發之韻
• 作者：KIM MAN LUI KEITH C.C. CHAN
• 譯者：楊 艷  丁大江  倪禕昭  王天驕
• ISBN：978-7-121-10816-7
• 頁數：316頁
• 定價：39.00元
• 出版社：電子工業出版社
• 出版時間：2010年5月
• 開本：24開

編輯推薦

軟體開發之韻一書於2010年由電子工業出版社出版發行。該書是一本關於推薦、推廣、推崇敏捷開發的軟體方法學教材，這種方法同時尊重人員與實踐的軟體開發的雙重韻律。該書以軟體開發實踐中的點滴作為出發點展開討論，描述了一些項目片段和工業實例，注重用事實說話。適合閱讀該書的人員包括：處在軟體行業第一線的程式設計師、各個軟體開發單位的團隊領導、項目主管、高層管理人員，以及人力資源經理、文檔撰寫人員、程式開發工具的設計者、程式開發語言的設計者、所有其工作與程式開發有關的人。

內容簡介

全書包括兩部分，共9章。第一部分由三章組成。第1章介紹軟體開發韻律的概念，第2章、第3章分別討論人與實踐，闡明軟體開發的一些基本概念並提出幾個重要的問題，如：“什麼是敏捷價值？”“從開源軟體開發中我們能學到什麼”等。第二部分包括其餘的六章，都是關於開發韻律的。軟體開發韻律是一個強大的比喻，可幫助我們分析何時更好地採用一種軟體開發的方法，使軟體開發實踐更加和諧，軟體的質量也得以提升。

全書行文深入淺出，親切自然，並配以很多有趣的漫畫來闡述書中的概念，值得讀者細細品讀，定當回味無窮。

前 言

本書幫助我們發現自己的軟體方法學，這種方法同時尊重人員與實踐的軟體開發的雙重韻律。

深夜，躺在馬拉威湖的康帝海灘，我們仰望晴朗的天空。無數小星星向我們眨著眼。有一點疲倦，或許是這遙遠神秘的光使人迷幻，我們閉上眼睛，開始傾心聆聽：湖水輕柔地拍打著岸，深夜那微小和諧的聲音，心好像隨著有韻律的、深深的呼吸而悸動。大自然就是一曲不可思議的韻律合奏。我們的地球在太陽系的軌道上轉動不息，日日夜夜，四季循環，永不休止。隨著自然的韻律，我們醒來學習，入睡記憶，寫寫改改我們的程式，在完美的韻律合奏中與宇宙間全能的程式融為一體。從心跳到步伐，韻律是動力十足、充滿生機的力量。這世界如此複雜、好似混沌，我們努力追求緣由並確認關聯，但有時只有發現韻律才可以讓我們看到普遍存在的規律。

就像人類其他的努力一樣，軟體開發複雜並充滿了泛化與關聯，但是沒有規則。我們用規範的軟體開發模型和管理學幫助構造軟體，但是紛擾的軟體開發、不斷變化的開發團隊、新的需求與任務，意味著根本無法保證上一次成功的方法就能在下一次同樣成功。實際上，有的團隊領導看上去並沒有採用什麼開發方法，因而被別人嘲笑是“即興開發”，他們反而能夠按時完成軟體項目。他們成功的秘密就在於能夠理解軟體開發的韻律。

面對最讓人頭疼的軟體開發問題，了解韻律將給予我們一個新的視角。一個團隊的成功方法有時並不適合另一個團隊，因為即使是最積極肯乾的軟體團隊，也必須在理解一種新方法的韻律後，才可以成功地得以運用。在管理複雜而多元的軟體開發項目時，團隊和個人的開發與進程之間的和諧運作是最關鍵的，然而韻律卻是一個經常被忽視的主題。

韻律並不是一種新的開發方法。當前已經有許多種不同的開發方法，本書並不打算介紹一種新的軟體開發和項目管理的框架。目前最需要的不是更多的方法，而是更智慧地使用我們選擇的方法。最好的方式是，理解並和諧地在團隊所採用的開發方法的韻律下工作。如果不理解，不在韻律下和諧地工作，則反而會被選用的開發方法拖累而並非從中受益，會使項目冗長艱難。

本書不是為新手所寫的。實際上，我們認為你可以釣魚並已經釣到了一些魚了。本書是為了那些老手，想改進甚至於想重新發現軟體開發的技巧與技術的人而寫的。當我們習慣於只從一個單一的角度看問題時，這些東西很容易被遺忘。就像正在釣魚的人，用靈巧的手腕，穩定的韻律甩出魚線，我們希望能幫助你釣到更多的魚，並幫助你享受這一過程。

讀者

我們盡力用平易的語言寫一本技術書籍。那些對軟體開發和項目管理有興趣的人（例如軟體經理、程式設計師、研究人員，等等）看此書應該沒有任何問題，因為對於任何在這個領域外的術語，我們都提供了解釋和清晰的例子。

與肯特·拜克的《解析極限編程》（第2版）一道，此書可以作為敏捷軟體開發的高級教材。本書描述了一些項目片段和工業實例，適合於實例學習，也可以向學生展現將來團隊合作項目的基本知識。此書也是一本論文專著，因為書中提出了很多概念，這些概念之前沒有在工程管理和軟體工程的學術論著中充分和適當地予以考慮過。

本書面向廣泛的讀者群，尤其針對那些有思想深度的讀者，那些尋找有創意的項目管理解決方案並對軟體開發的複雜領域進行探索的人。

怎樣讀此書

一般來說，我建議按章節順序讀。本書包括兩部分。第一部分由三章組成。第1章介紹軟體開發韻律的概念。第2章、第3章分別討論人與實踐，闡明軟體開發的一些基本概念並提出幾個重要的問題，例如：“為什麼我們不可以從經驗中學習？”，“什麼是敏捷價值？”，“怎樣才可以衡量不同的無形的軟體開發工作孰輕孰重？”，還有“從開源軟體開發中我們能學到什麼？”

本書第二部分都是關於軟體開發的韻律。我們過去常常用相似的術語：進程，實踐。雖然不是每個人都自信知道它們之間的差別，但我們是在軟體開發實踐的基礎上譜寫韻律。當我們分析何時更好地採用一種軟體方法時，軟體開發韻律是一個強大的比喻。為了更有效地展現這一點，我們採用了一些有爭議的軟體實踐並且考慮它們的韻律，將它們與其他一些廣泛接受的軟體實踐進行比較。

一旦你理解了軟體韻律分析是怎樣使實踐更加和諧的，你就可以作為一個中間步驟，採用本書呈現的韻律或者盡情修改它們。然而，最重要的是意識到：韻律不是模型，最終我們都需要譜寫自己的韻律。

鳴謝

本書涉及幾個軟體開發領域之外的概念和觀點。幸運的是，眾多這些領域的著名專家給我們提供了友善的建議和指導，讓我們深深受益。對於他們寶貴的時間和專業的建議，我們的感激無以言表。下面按字母順序列出了他們的名字：

Paul Davies，審定了我們關於物理學家和結對編程的描述；

Don Forsyth，從很多動態視角提供了他關於結對編程的洞察；

Michael McClellan，審核了本書的音樂符號；

Richard Schonberger，審核了有關精益製造和工程項目的部分；

Frank Vigneron，對天使的性別進行了討論；

Joel Watson，審核了“成交還是不成交”和博弈理論的類比；

Philip Zimbado，關於他的監獄實驗給了我們建議。

許多資深程式設計師都審閱了本書的一到兩章並提供了寶貴的意見，對此我們深表感謝。十分感謝（以字母表順序）：Lawrence Bernstein, Grady Brooch, Magne JØrgensen, Pete McBreen, George Metes, Peter Middleton, Mark Paulk, Ioannis Stamelos, Royce Walker和Sami Zahran。

感謝Martin Kyle給我們提供了有用的建議：用平白的語言書寫。我們感謝John Nosek對合作編程的見解和對本書的貢獻。我們非常高興有Angappa Gunasekaran的支持。我們感謝Lai Shan Sit用很多有趣的漫畫來解釋我們的觀點。感謝我們的朋友和同事Jun Wang，Zheng Li，Polly Leung，Fei Dong，Ka Wing Wong，Whitney Lesch和Rosalyn Farkas的協助。

最後，我們尤其感謝兩個人。感謝Kent Beck啟發了我們在軟體開發韻律方面的研究。Kent向我們建議了應該集中在哪些選題上，他還審查了整個手稿。感謝Paul Petralia，我們的編輯，他告訴我們從最開始他就喜歡這本書的概念。他說這本書將促進人們用新方法思考老問題，沒有他的鼓勵就沒有這本書。我們全都相信軟體開發韻律是一個強大的解決方案和有效的管理工具，這不是巧合。韻律不是方法，它更像元方法，是一種開發新軟體方法的方法！

KIM MAN LUI

KEITH C. C. CHAN

2008年1月於中國香港

譯者序

這是一本關於推薦、推廣、推崇敏捷軟體開發的教材。2008年初識此書，幾章讀下來，思維方式受到了巨大衝擊。這不僅是一本指導軟體開發實踐的參考書，更是轉變軟體開發思維的工具書。後來有了本書其他譯者的加入：具有豐富專業知識和經驗的丁大江、倪禕昭和楊軍，軟體開發愛好者王天驕和張靖。在本書翻譯的多次討論中，我們都感覺到由這本書帶來的思維方式的衝擊是深刻的，不只影響了軟體開發思維，甚至拓寬了學習、工作的思維方法。本書主要介紹軟體開發韻律，是一種開發軟體的新思維，一種軟體工程管理上的革命！

我國有最好的程式設計師，他們勤奮、好學，不厭其煩地一遍遍書寫並修改代碼，而軟體的管理水平卻亟待提高。隨著幾十年軟體開發的發展，軟體管理也面臨著從粗放到集約的轉變，除了編寫軟體外，我們開始關心如何做好、做出易管理的、低耗而高效的軟體產品，這些都是我們未來軟體管理的核心發展方向。

這本書中談到技術與管理的關係，將人的因素加入軟體工程管理範疇，與我在交通心理學中進行的研究不謀而合，也因此引起了我極大的興趣。人作為整個系統的核心因素，卻常常被遺忘在技術的背後。本書綜合考慮軟體工程中的各個環節，將其作為一項系統工程，而非單純的日程表和編碼。作者通過借用大量心理學範圍的理論和實例闡釋了程式設計師的因素對軟體開發的影響，從而有力地說明：一種先進的軟體開發及管理方法必須對人的因素進行細緻而徹底的研究。

與其他程式設計教材相比，本書更注重用事實說話，以典型案例為根基，以分析為支柱，建設敏捷軟體開發的殿堂。作者依靠詳實的案例和豐富的軟體開發管理經驗對採用敏捷軟體開發的原因、環境和原則進行了獨到的分析與闡釋。作為一本面向程式開發團隊的管理教材，作者的目的在於向團隊的管理層推薦敏捷軟體開發的概念、推廣敏捷組隊等團隊形式，以及推崇軟體開發韻律這一嶄新的理念。所有的方法論變革看似突然、巧妙，仔細回味卻又覺得按部就班、理所當然，讓人覺得水到渠成又感到無所適從。到底應該用什麼樣的方法解決問題？如何面對內外部環境的變化？在這本書裡面，頻繁出現的一個詞給了我們啟迪，這個詞就是“韻律”。

作者以提高軟體質量為目的，針對敏捷開發，從易於理解的、創新的視角向讀者闡述了軟體開發的“韻律”，即“在敏捷實踐的基礎上，如何採用其中一種開發方式並使它與另一種開發方式相結合，以實現一種協同作用，從而使它們在協同工作方式下所發揮的效用比它們單獨使用更加強大”。

書中有眾多工業上經典精彩的實例，加上語言上幽默精闢的分析，讓每個結論都顯得紮實、飽滿、讓人信服。以譯者揣摩，作者更傾向於向團隊管理人物銷售軟體開發韻律的理念，而非手把手地指導敏捷軟體開發的流程。相較於其他程式設計書籍豐富詳實的編程實例，此書對編程代碼方面僅是點到即止。

作者的行文方式令人印象深刻。比起普通程式設計教材生硬刻板的論述，此書常以軟體開發實踐中的點滴作為出發點展開論題。如此行文，親切自然，更另諸多非程式設計師（比如團隊的管理者、組織者）能夠輕易地了解作者的意圖，書中雖然涉及了目前軟體管理中的大部分先進概念，但並不晦澀難懂。作者繞開軟體開發的種種術語，旨在給讀者介紹更高層的管理理念。本書附有大量生動的圖表，採用一種輕鬆活潑的風格寫成；書中還包含許多有趣的小故事以及來自實際生產的案例分析，使讀者身臨其境、易於理解。比如，心理學理論往往是比較抽象的，而本書的作者卻用平實樸素的語言，加以大量有趣的測試和實例解釋了編程心理學的相關知識。更獨到的是，這本書創造性地用五線譜來描述軟體開發的韻律，通過五線譜把兩個以上的軟體實踐和諧地掌控起來，使讀者能更深刻地感受，去探索軟體開發的節奏和韻律。

本書共有9章，涵蓋了軟體開發韻律學的理念、套用、實例及其注意事項的方方面面。其中第1章和第4章由丁大江翻譯，第5章和第7章由倪禕昭翻譯，第6章和第8章由王天驕翻譯，第3章和第9章由楊軍翻譯，第2章由張靖翻譯，全部譯稿的統編和校對由楊艷完成。所有的翻譯和校對工作歷時大半年，在此，我要感謝為本書的出版付出辛勤汗水的電子工業出版社博文視點公司的編輯，他們嚴謹認真的工作使該譯本可讀性更高，她們高漲的工作熱情深深感染著我努力將最好的版本奉獻給讀者。希望這本書除介紹給讀者有用的知識外，也能帶給您閱讀的享受。

希望本書的中文版能夠促進讀者們之間的交流。同時，翻譯之中的不妥和疏漏之處，還敬請讀者批評指正。

楊艷

2010年3月3日於英國

目 錄

第一部分：基本概念

第1章 程式設計師不死

1.1 開發軟體與修建隧道相比

1.1.1 美好的舊時光

1.1.2 情況越變化，他們越相同

1.1.3 軟體產品的背後

1.1.4 成交或不成交

1.2 哆來咪哆來咪

1.2.1 疊代模型

1.2.2 編碼後修復模型

1.2.3 混沌

1.2.4 重要的方法

1.3 軟體開發韻律

1.3.1 五線譜示例

1.3.2 博弈理論

1.3.3 啟動－結束示圖（In-Out Diagram）

1.3.4 精通－培訓示圖

1.3.5 不用數學

1.3.6 去哪裡探索韻律

參考文獻

第2章 了解程式設計師

2.1 個性及智力

2.1.1 編程高手

2.1.2 了解你的團隊

2.1.3 招募程式設計師

2.2 外包程式設計師

2.2.1 本土化的程式設計師

2.2.2 程式設計師，文化及團隊

2.3 經驗式管理

2.3.1 對待因果關係不嚴謹

2.3.2 謹慎借用經驗

2.3.3 從現在做起

參考文獻

第3章 從開源做起

3.1 流程和實踐

3.1.1 項目的四個P

3.1.2 敏捷的價值

3.1.3 零起點合作

3.2 開源軟體開發

3.2.1 軟體克隆

3.2.2 軟體質量

3.2.3 啟動流程

3.2.4 開源開發團體

3.2.5 用戶程式設計師

3.2.6 參與者角色

3.2.7 快速發布

3.2.8 黑盒編程

3.2.9 OSS實踐

3.3 類OSS開發

3.3.1 敏捷實踐

3.3.2 近鄰交流

3.3.3 松耦合和緊耦合

3.3.4 同一地點的軟體開發

3.4 結論

參考文獻

第二部分：韻律

第4章 抄襲編程

4.1 抄襲

4.1.1 已有的代碼

4.1.2 社交網路分析

4.1.3 被抄襲

4.1.4 讓人人成為程式設計師

4.1.5 模式語言

4.1.6 軟體團隊能力

4.1.7 粗線條設計

4.1.8 培訓不是解決方案

4.2 抄襲最快

4.2.1 不道德

4.2.2 無先例的代碼

4.2.3 人際關係網

4.2.4 抄襲的韻律

4.2.5 工作中抄襲

4.3 抄襲的生意與韻律

4.3.1 15分鐘的商業報告

4.3.2 市場調研

4.3.3 聊天機器人

4.3.4 老歌新唱

參考文獻

第5章 結對編程

5.1 藝術與科學

5.1.1 最佳搭檔

5.1.2 喧鬧的程式設計

5.1.3 僅僅是培訓

5.1.4 付費給觀眾

5.2 兩個世界

5.2.1 沒錢的世界

5.2.2 金錢引導的世界

5.2.3 經濟學

5.2.4 虛構的質量——時間關係

5.2.5 加速運行時間

5.2.6 關鍵路徑法

5.2.7 為什麼是兩個結對而不是三個：反組織現象

5.2.8 軟體的需求是個拼圖

5.3 程式設計任務需求

5.3.1 2+4=6

5.3.2 2+4=4

5.3.3 2+4=3

5.3.4 2+4≥2

5.3.5 2+4=?

5.4 結對編程不僅僅是程式設計

5.4.1 用代碼設計

5.4.2 結對設計

5.4.3 韻律結對編程

5.5 結對編程團隊指導

參考文獻

第6章 重複編程

6.1 結對編程的爭議

6.1.1 編程是一項特殊的工作嗎

6.1.2 三個腦袋是否比兩個好

6.1.3 不可重複的實驗

6.2 重複編程

6.2.1 相反的結果

6.2.2 原理

6.2.3 三人一組編程的效率不高

6.3 旋律：結對-單獨-結對-單獨

6.3.1 持續性

6.3.2 聯繫

6.3.3 動機

6.4 證明布魯克斯法則的一個特例

6.4.1 士氣低落

6.4.2 溝通的成本

6.4.3 適用於延誤項目的旋律

參考文獻

第7章 敏捷組隊

7.1 項目團隊

7.1.1 自組織團隊

7.1.2 團隊中的團隊

7.1.3 項目團隊的組成

7.1.4 團隊生命周期與學習曲線

7.2 生產力

7.2.1 生產力的錯覺

7.2.2 集體代碼所有權

7.2.3 責任、職責和透明度

7.3 問題與出問題的人

7.3.1 旋律：困難——重組

7.3.2 組隊原則

7.4 拯救即將失敗的項目

7.4.1 項目紅綠燈報告

7.4.2 一個商業案例

7.4.3 指導委員會會議

7.4.4 敏捷組隊發揮作用

7.5 提防Iago（埃古）

參考文獻

第8章 增量設計

8.1 建模和計畫

8.1.1 敏捷計畫

8.1.2 使用功能性模組進行設計

8.1.3 簡潔設計

8.1.4 總體成本的概念

8.2 返工還是復用

8.2.1 無法避免的返工

8.2.2 即興創作

8.2.3 預先設計

8.3 即時的軟體開發

8.3.1 CMM的旋律

8.3.2 一次工廠參觀

8.3.3 走來走去的工人

8.3.4 即時軟體開發

8.3.5 增量式設計

8.4 需求複雜性

8.4.1 遺漏的需求

8.4.2 衝突的需求

8.4.3 迅速改變的需求

8.4.4 需求和設計

8.5 重構

8.5.1 重構活動

8.5.2 通過挑戰進行重構

8.5.3 為了設計模式進行重構

8.5.4 故意製造錯誤

參考文獻

第9章 測試驅動開發

9.1 逆向瀑布

9.1.1 設計-編碼-測試

9.1.2 測試-編碼-設計

9.2 測試優先編程

9.2.1 測試和驗證

9.2.2 斷點測試

9.2.3 支撐實踐

9.3 韻律：測試-編碼-重構

9.3.1 簡單的案例

9.3.2 自動操作

9.3.3 意識革命

9.3.4 用來合作的測試案例

9.4 快速的軟體過程升級

9.4.1 培訓程式

9.4.2 項目規劃

9.4.3 項目跟蹤

9.4.4 軟體質量

9.4.5 軟體配置

9.4.6 人員紀律

參考文獻

尾聲 各種樂聲的混合

開發旋律和您

適用於具有更多重複性編程任務的開發旋律

適用於具有挑戰性的任務的開發旋律