麥克布林編著的《軟件工藝》在“如何訓練下一代開發者”方面提出了很有價值的觀念。不僅如此，本書還涉及到了軟件的哲學。工藝學所針對的是個人的能力：對你的工作，對你個人的發展，對於你的職業，工藝學能給你*多的幫助。它並不干涉你開發軟件的工作方式。你可能在通過了CMM 5級的企業中朝九晚五循規蹈矩地工作；也可能為了實現又一個驚天動地的新點子而一周工作100小時，靠咖啡因來驅散倦意。

麥克布林編著的《軟件工藝》針對軟件開發，提出了一些相當棘手和敏 感的問題，並給出了頗具爭議性的結論：從一個數百年來一直興旺發達的繫 統——工藝學中獲得啟示，尋找答案。 《軟件工藝》用5個部分共19章的篇幅，繫統地闡述作者的觀點，並試 圖回答一直困擾著軟件行業的難題——我們應該如何重組軟件構造的過程， 使其能夠如我們所願地有效運轉？第1部分共4章，對傳統的觀點提出質疑— —軟件工程真的是解決軟件開發問題的靈丹妙藥嗎？第2部分共2章，這一部 分提出了本書的觀點，即以軟件工藝的視角看待軟件開發。第3部分以7章的 篇幅，從不同的角度全面地展現了軟件工藝理論所帶來的主要變化，以及如 何實踐這個觀念。第4部分共3章，對比了軟件工藝與軟件工程，並為各自適 用的範疇重新劃定了界限。第5部分共3章，分別討論軟件開發中的權宜之計 和長期問題。 《軟件工藝》榮獲2002年度Jolt圖書大獎。閱讀本書，有助於引發讀者 在軟件開發問題上的獨立思考，《軟件工藝》適合軟件行業的所有從業人員 閱讀參考。

**部分 置疑軟件工程
第1章 理解軟件工程
軟件工程的悖論
等待硬件開發時，軟件開發者在干什麼？
得到可用的硬件之後，軟件開發者如何加快交付的速度？
傳統開發過程的內蘊
軟件工程的當代解讀
“足夠好”的軟件—庶民的軟件工程
軟件工程適合你的項目嗎？
第2章 軟件工程的困境
“有組織的、可計量的”軟件開發過程現實嗎？
我們當然可以將軟件開發中的某些部分自動化，不是嗎？
“足夠好”的軟件開發方法的危害
誰能取代軟件工程？
第3章 理解軟件開發
軟件資產
軟件開發需要團隊協作
軟件開發的分工有用嗎？
沒有一勞永逸
尋找比“軟件工程”*合用的隱喻
第4章 尋找一個比軟件工程*好的隱喻
軟件開發的工藝
與傳統工藝學的比較
軟件開發工藝的復興
第二部分 軟件工藝
第5章 重拾軟件開發
工藝學致力於改善軟件開發的現狀
工藝學鼓勵開發者編寫**的軟件
吹響號角
第6章 無須執照的工藝學
工藝是私人性的
同行認可和**是獲得*好軟件的辦法
執照隻是假像
執照是在向風車開戰
工藝學關注個人
軟件開發者不是太少，而是太多
第三部分 軟件工藝隱含的意味
第7章 工藝學對繫統的用戶有何影響
軟件容易拷貝，所以軟件工藝能夠有效
批量市場的難題
工匠與用戶有一種不同的關繫
但是，請記住：購買者很可能不是使用者
**的軟件應該簽上開發者的名字
為作品簽名會使情況發生變化
工匠應當對作品負責
工匠需要挑剔的用戶
*小、*堅固的軟件*有利於用戶
軟件工藝帶來協作式開發
第8章 顧客與工匠的關繫
給我一個真實的交付日期
揭穿“足夠好的軟件”的謬論
另一種選擇
不要隻考慮出價*低的開發者
差勁的客戶將很難吸引**的開發者
讓軟件工匠因為自己的作品而獲得榮譽
要求開發者對作品負責
利用開發者之間的差異
雇傭**開發者組成的小團隊
**的開發者究竟值多少？
但我們如何知道開發者有多**呢？
根據交付的成果來衡量開發者的水平
在選擇工匠時，客戶在成本和質量之間作出權衡
軟件工匠的專業分工
客戶與軟件工匠有長期的聯繫
維護者是一個榮耀的身份
軟件工藝有益於長期使用的軟件
客戶與軟件工匠志趣相投
第9章 工匠的管理
軟件工匠不是雇工
好的開發者比管理者*有價值
軟件開發的實際過程無法詳細定義
軟件工匠與管理者的關繫
以管理**的開發者為樂為榮
**的管理者理解項目的節奏
軟件工匠喜歡創造軟件
軟件開發的根本從來沒有改變過
家有一老，如有一寶
軟件工藝要求全新的管理方式
軟件工藝不是“有計劃報廢”
軟件工匠堅持自己的要求
**0章 成為軟件工匠
軟件工藝拒*精細的分工
過度的專業化會延誤開發、導致錯誤
軟件工匠建造能夠理解的繫統
工藝學需要獻身精神
如何成為軟件工匠？
學徒是比學校教育*有效的學習方式
技師是工藝學傳統的關鍵
工藝學傳統已經延續多年
**1章 工藝的掌握
軟件工藝大師是什麼樣子？
善用你的老員工
“掌握技藝”意味著使用穩定的技術
軟件工匠不會僅僅因為工具“*新*好”而使用它
軟件工程對COBOL的謀殺
技藝需要花時間去掌握
“掌握”意味著承擔起傳遞工藝的責任
工匠挑選學徒和技師
**2章 學徒開發者
我們必須扭轉開發者培訓質量下滑的局面
大學文憑與項目開發無關
會編程不等於會開發軟件
如果必須送初學者去培訓，選擇好的培訓課程
工藝的掌握，學徒比培訓*有效
成為學徒是重要的一步
為了降低對工作的影響，工匠慎選學徒
重要的是學，不是教
學徒不是學校
活到老學到老
學徒審查師傅的作品，並從中學習
學徒的角色
從低風險的任務開始
晉升到產品開發
因為能力而晉升
學徒不是廉價勞動力
學徒期是時間和精力的投資
學徒如何成為技師
**3章 技師開發者
技師在工藝學傳統中的位置
技師開發者
技師很少單獨工作
技師關注應用程序的交付
技師在軟件工藝中扮演關鍵角色
第四部分 重新定位軟件工程
**4章 軟件工程項目
軟件工程的目標是大型繫統項目
軟件工程需要專業分工
軟件工程項目依舊使用瀑布過程
編程是一項刻板的工作
軟件開發不是軟件工程項目的瓶頸
形形色色的軟件工程項目
敏捷方法代替縝密的軟件工程
**5章 “軟件工程”隱喻的危害
無法以低成本實施軟件工程
魚與熊掌可以兼得？
相信估算軟件工程項目的確需要很長的時間
軟件工程鼓勵“科學管理”
軟件工程輕視不**的討論
軟件工廠：軟件的生產線
跨項目復用極難實現
冒險的“長時間復用”
“標準軟件開發過程”的迷思
傳統的分工無助於軟件開發
“*佳實踐”是“科學管理”的遺毒
*佳實踐使人墨守成規
*佳實踐阻礙了過程革新
軟件工程強迫我們忽視個人
軟件開發者不是可替換的資源
偽造一個“理想的開發過程”
開發過程，不嫌其多
拋棄軟件工程的瀑布式過程
瀑布方法需要大型團隊來實施
小型團隊*不要嘗試軟件工程
**6章 學習軟件工程的經驗
尺度和復雜度
做軟件，不容易
應用程序需要良好的結構
變化的代價很高——如果你不允許變化的話
交流至關重要
文檔總是錯的
用增量式開發來控制風險
**的估算很難得到
借用這些經驗
第五部分 星期一的早上
**7章 經驗——項目成功的指示燈
根據聲望選擇軟件工匠
信任工匠的**
*後，開始大範圍搜索
根據聲望和作品來評價工匠
考察工匠的作品
工匠的試演
由軟件工匠來組建開發團隊
根據個人了解和**挑選團隊成員
年富力強的開發團隊
為低預算團隊擔心
通力協作
使用增量式開發
盡早解決問題
任何人都能學會協作式開發
回避**技術
經驗的價值
他們去年在哪裡？
獎勵**開發者
想要人纔，就得付高薪
我們付得起那麼多錢嗎？
做好喫驚的準備
**8章 為測試和維護而設計
是軟件應用，不是軟件項目
應用程序隻會退休，不會結束
維護團隊理應拒*丑陋的軟件
可維護軟件需要有自動測試
使應用程序能夠被測試
為維護而設計
創建可維護軟件需要經驗豐富的開發者
可維護軟件能夠生存多年
長壽的應用程序需要長壽的開發工具
開放源碼，軟件工藝的*愛
Java對項目的健康有害
可維護軟件需要穩定的基礎設施
**的軟件是**性的
保證軟件的**性
拒*“有計劃報廢”
**的軟件需要**的用戶界面
能夠安全使用的軟件
可維護軟件易於診斷
外包的危害
外包忽視了軟件開發的本質
在外包中堅持軟件工藝
借助外來的工匠
維護是軟件生命中*重要的部分
提高維護者的地位
維護者當受賞
並非所有軟件都必須可維護
“為測試和維護設計”不能一蹴而就
**9章 活到老，學到老
創造學習的環境
用內部研討創造學習環境
邀請所有人參加講座
學習時間是一種投資
掌握軟件開發的技藝
鼓勵參加用戶組和技術會議
慎選培訓課程
課前聯繫
課後跟蹤
亡羊補牢
鼓勵員工活躍於開發者社群中
鼓勵出席技術會議
鼓勵開發者擔任講師
鼓勵開發者寫書
沉思的實踐者