編程匠藝——編寫卓越的代碼
編程匠藝——編寫卓越的代碼
韓江 譯
ISBN 978-7-121-14347-2
2011年10月出版
定價：85.00元
16開
660頁
內容簡介
如果你可以編寫出合格的代碼，但是想更進一步、創作出組織良好而且易於理解的代碼，並希望成為一名真正的編程專家或提高現有的職業技能，那么《編程匠藝——編寫卓越的代碼》都會為你給出答案。本書的內容涵蓋編程的各個要素，如代碼風格、變數命名、錯誤處理和安全性等。此外，本書還對一些更廣泛的編程問題進行了探討，如有效的團隊合作、開發過程和文檔編寫，等等。本書各章的末尾均提供一些思考問題，這些問題回顧了各章中的一些關鍵概念，可以促使你像專家一樣思考，從而使本書成為那些渴望作為團隊的一分子，職業並高效地編程的新手們的一本絕佳的參考書。
作者簡介
Pete Goodliffe是一位軟體開發專家，他在軟體“食物鏈”上從未駐足不前。他在各種各樣的項目中使用過許多種語言。他還在教授和指導程式設計師方面有著豐富的經驗，並且常年為ACCU的C Vu雜誌撰寫欄目“編程的職業化”。Pete痴迷於編寫出色的、沒有錯誤的代碼，這使得他有更多的時間與自己的孩子共度美好時光。
讚譽
本書在正式發行之前所獲得的讚譽
“為了掌握某種技藝，不僅僅需要訣竅和工具，還需要態度和技能。對於那些真正用心的程式設計師來說，這就是他們可以從《編程匠藝——編寫卓越的代碼》一書中學到的東西。在許多代碼猴子形象（譯註：本書採用的卡通形象）的幫助下，這本書鼓勵讀者對他們所從事工作進行反省和思考。”
——Kevlin Henney，獨立諮詢師
“容易理解，非常吸引人，甚至常使人忍俊不禁。這本書是從多年的實際工作中提煉出的智慧，飽含著軟體開發世界的辛酸和甜蜜……真希望我剛開始當程式設計師的時候能夠擁有這本書。”
——Steve Love，資深開發人員
“《編程匠藝——編寫卓越的代碼》是一座知識的金礦，每位職業軟體開發人員都應該掌握這些知識。”
——Tim Penhey，C VU編輯
“良好的判斷來源於經驗。而經驗——是的，卻來源於你所作出的糟糕的判斷！這本書是一個機會，可以讓你從別人艱難得來的經驗中學習，從而少走許多彎路。”
——Lois Goldthwaite，C++和POSIX BSI標準委員會的召集人
“這就是那種你應該給新員工們看的書。它講的都是事實，很容易理解，並且涵蓋的主題範圍極廣，這些主題都是新入行的程式設計師們應該搞明白的。”
——Jon Jagger，軟體培訓師、設計師、諮詢師、導師、程式設計師
“這是一本獨特的、極為實用的指南，可以指導你成為現代軟體工廠中的一名職業程式設計師。”
——Andrew Burrows，軟體開發人員
“Pete擁有一種罕見的能力。他不僅能指出最優秀的職業軟體開發人員們所使用的技術（他們自己往往都沒有意識到），還能用一種清晰和簡明的方式來描述它們。”
——Greg Law，Undo Ltd的CEO
“我真希望在我職業生涯的初期接受指導的時候就能讀到這本書。至少，現在我可以用它來指導跟我學習的程式設計師。”
——Dr. Andrew Bennett，高級工程師、工程學學士、博士、MIET、MIEEE
“那些有幸聆聽過Pete Goodliffe的演講的人，都能馬上識別出他那輕鬆幽默、清晰明了地闡述問題的方式。在教學的環境下，這本書可以直接用來作為教材，不論是新手還是有經驗的從業人員，都能從中學到東西，並得到提高。”
——Robert D. Schofield，碩士、MIET FOUNDER、Scientific Software Services Ltd.
“Pete要闡明的不僅僅是怎樣編寫代碼，而且還有怎樣更好地編寫代碼，讓程式設計師們能夠在工作中使用正確的工具和技巧。《編程匠藝——編寫卓越的代碼》這本書廣泛地探討了編程的各個方面，書中所提出的原則是所有重視工作的開發人員都應該熟知的。”
——Chris Reed，軟體開發人員
“Pete Goodliffe對促進軟體開發職業化的貢獻，在業界是有目共睹的。憑藉他那讓人信賴的知識，以及風趣和詳實的寫作風格，不管是對於新手還是對於有經驗的開發人員來說，Pete都可以稱得上是一名出色的導師。”
——Rob Voisey，Akai Digital Ltd.的技術總監
“我最喜歡書中的代碼猴子形象。”
——Alice Goodliffe，四歲半
再序
這本書能夠重印，本身就說明了它的價值獲得了讀者的認可，在今時今日，已屬不易。所以時隔三年，我雖然已經不在原來的工作崗位上，也還願意再就這本書說幾句。
這本書講了什麼呢？其實也沒什麼屠龍秘笈，無非還是關於軟體編碼的一些普普通通的大實話，一些實實在在的經驗之談。它的優點，一是比較完整，二是具體而又簡明，三是樸實。總的來說，我覺得這本書比較好地概括了軟體開發當中真正行之有效的東西，而且不包含花哨的噱頭。這是難能可貴的。
軟體開發行業還沒有完全走出青春期，離成熟還遠。行業跟人一樣，所謂成熟，就是說試過了很多想法，狂也狂過了，瘋也瘋過了，痛定思痛，返璞歸真的那么一種狀態。軟體開發這個行業，給狂想提供了特別大的舞台。每個程式設計師都希望成為高手，而高手似乎就要體現在各種各樣炫酷的代碼、框架、程式庫上面，所以各種看上去很酷的想法層出不窮，程式設計師們周期性地為最新的時髦辭彙而痴狂。但是這么多年的實踐，很多人其實還是看明白了，大多數酷炫絕技最後身敗名裂，塵歸塵土歸土，留下來經久不衰的，還是那些低調、樸實、透明的技術。這本書里講述的，大多數屬於長期沉澱結晶出來的東西，所以值得信任。
幾年前，我參加一個技術會議，一位發言人是程式設計師出身的天使投資人，他在評價另一個靠技術成功的年輕人時說，那個某某某，其實技術很平庸，但是他為什麼成功？因為他做出了一流的產品，而且是個商業天才，所以成功了。很有意思的一段話，做出了一流的產品，技術水平還能叫“平庸”嗎？軟體開發行業有一個特別熱鬧而且旁若無人的圈子文化，大多數開發者都在圈子裡不亦樂乎，不是拿成果，而是拿點子來比高下，把大部分精力用來取悅同行。不過我提倡開發者經常站在圈子外面審視自己，這樣會比較容易保持頭腦的清醒。歸根結底，社會還是以你是否能交付高質量的、易於維護和擴展的產品來評價你的能力和水平，並且給予你相應的待遇。所以開發者到底應該怎樣規劃自己的發展路徑，其實是值得反思的。
我覺得這本書好就好在沒多少花花架子，都是實實在在的好東西。所以即使是三年以後，五年以後，也還值得再讀。
孟 岩
2011年7月於北京
推薦序
信息產業幾乎是開放程度最高的產業，其發展之快，讓身處其中的我們既感到興奮和激動，也時常困惑和惶恐。信息技術的變化太快、太激烈，一切都在迅速革新當中，作為技術人員，我們今天熟悉並且賴以安身立命的東西，很快就會變成故紙堆里的古董。人生總是需要不斷積累才能越走越高的，如果找不到一項可以積累提升，而且被市場所承認的核心競爭力，事業的大廈是建不起來的。於是一個嚴峻的問題就擺在每一個技術人員的面前——什麼才是我們的核心競爭力？
二十年前，人們認為軟體開發者的核心競爭力應該體現在他的聰明才智和紮實的基本功上，要精通算法、硬體、編譯、計算機體系結構，要有天馬行空般的想像力和創造力，能夠單槍匹馬單打獨鬥。至於什麼團隊協作、編碼規範、單元測試、最佳實踐，都是對天才的不必要的羈絆。
大約到了20世紀90年代中期，風水變了。隨著軟體的規模越來越大，以及當代作業系統、面向對象技術、軟體開發工具、程式庫和框架的普及，“平台”和“工具”變得越來越重要了。大多數時候，開發者不需要自己從頭實現所有功能，他所依賴的平台已經準備好了現成的組件供使用，有的時候甚至應用程式中最繁瑣、最複雜的部分已經由框架或程式庫實現好了。因此，人們普遍認為，一個開發者的核心競爭力很大程度上表現為對平台與工具的理解和掌握，並依託這種理解創造性地構築產品，或者更確切地說，一種創造性地組裝產品的能力。你還在為剛剛琢磨出來的一個高效算法而得意嗎？旁邊那位藉助程式庫里提供的組件，已經快速地完成了整個功能模組；你發明了一個新的視頻格式以及對應的codec？很了不起！不過另一個初出茅廬、連快速傅立葉變換算法都寫不出來的團隊已經基於sourceforge上的開源組件做出產品來，並且播得滿網際網路都是了。當然，黑客們仍然有著不可取代的價值，總是能找到自己的位置；但是對於那些強調團隊作戰、快速行動的企業來說，一個熟練掌握MFC、Delphi、J2EE、 或者LAMP的開發者可能更實用，能更有效地為企業帶來價值。因此，這樣的程式設計師便一時成為企業的寵兒，眾人眼中的高手。
然而不到十年下來，問題又出現了。流行的平台和工具如走馬燈般你方唱罷我登場：昨天還在為領悟了MFC、Delphi而沾沾自喜，今天就發現套用主流已經是Web了；剛剛啃完艱深的EJB2，抬眼一看卻發現它已經被Spring的擁躉們批倒批臭了；上個月還是沖在敏捷Java領域的改革派，這個月就被一群嘴上無毛的ROR冬粉給劃到改革的對立面去了； 還沒學踏實呢，微軟又準備好 MVC、 AJAX、Silverlight等等一大堆新玩意讓你啃了。這樣下去，什麼時候是個頭？把自己的核心競爭力建立在這些轉瞬即逝的曇花上，難道不是把有限的生命投入到無限的瞎折騰之中嗎？難道只有鑽到一間舒舒服服的大公司里，到了三十多歲就尋求所謂的“轉型”，順著一條十分確鑿的“職場路線”攀或是混，最後在公司沒有倒閉或者自己沒有被“戰略裁員”的幸運之下頭頂玻璃天花板光榮退休，才是中國程式設計師的歸宿？什麼才是程式設計師可以長期積累，不斷提高，不但足以安身立命，而且能夠實現夢想、成就事業的核心競爭力呢？回答好這個問題，對於今天的開發者來說，可能比掌握和精通某項具體技術意義重大得多。
在我看來，當代程式設計師的核心競爭力至少應該體現在這么幾點上：有紮實的基本功，活躍的想像力與創造力，快速的學習能力，具備行業和領域知識，以及專業的軟體工藝能力。而在這其中，專業軟體技能是最基本、也是最重要的一項。
什麼是專業軟體技能呢？就是正確地開發軟體的能力，更具體地說，是通過一系列有組織的、有原則、流程化、可檢驗、可重複的實踐行為，協作式開發高質量程式的能力。對於一個程式設計師來說，這是你的看家老本，對於一個軟體團隊來說，這是你們的立足之基。算法不會，可以查資料慢慢掌握；不理解行業，可以邊做邊學，逐漸深入；缺乏創新，可以站在巨人肩膀上耐心摸索；甚至基本功不足，也可以自我彌補，可是如果沒有做軟體的專業態度和實踐技能，沒有製作合格軟體的工藝水平，連一段高質量的程式都寫不出來，試問你還剩下什麼？
經過近三十年的時間，人們最終認識到，在規模化團隊協作的情況下，決定軟體產品質量的不再是個人的聰明才智，也不是靠什麼神仙技術，而是團隊的工藝實踐。是否在一開始就形成了開發計畫？是否對這個計畫進行了必要的確認、維護和跟蹤？必要的規範文檔是否撰寫了？是否形成了合理的架構？是否恰當地選擇了開發工具和程式語言？是否建構了適於團隊漸進協作的良好的工具和工作平台？是否一開始就形成了有力的缺陷核查、控制和跟蹤策略並始終嚴格地執行？是否制定了連續一致的編碼標準，並且通過諸如代碼走查等加以保證？是否有完整的測試製度？是否具有明確的性能最佳化和軟體安全性保障過程？是否在整個生命周期貫徹了嚴格的版本管理、配置管理、發布管理和軟體維護退役管理措施？這些實實在在的問題，是需要耐心與細心地用具體實踐細節來回答的。當一個團隊對於這些問題都給出了明確而一致的回答並且用行動來執行的時候，他們就是一個專業的、具有核心競爭力的團隊。而當一個個體開發者能夠對這些問題具備正確的觀念，並且通過施加自己的影響力促進團隊向正確的方向前進的時候，他就是一個具有核心競爭力的開發者。一個具有核心競爭力的團隊和開發者，是可以不斷進步的，是具備把握機遇的能力的；一旦時機合適，他們就完全有可能實現更大的目標。
十多年以前國內外軟體界對工藝的問題並不重視。大部分人要么執迷於技術本身，指望某一天一個面向某某的技術能夠一勞永逸地解決軟體開發中的所有問題，要么就是把問題大而化之為“軟體工程”，企圖以指令性的方式，在巨觀的層面上用管理取代工藝。在這兩個方向上，程式設計師要么被視為可以充分放縱的孤膽英雄，要么被視為偉大編程技術最終出現之前不得不存在的過渡品，或者管理指令的機械的執行體，“人”的維度消失了。這種對於人和工藝細節的忽視也體現在技術著作方面。軟體工程、面向對象、編程技巧和產品手冊之類的著作汗牛充棟，而認真談到軟體工藝的書屈指可數。
直到20世紀90年代中期，隨著一些軟體產品的規模越來越大，微軟率先認識到工藝問題的重要性，於是出版了諸如《代碼大全》、《編寫清晰的代碼》等一系列探討這一問題的著作。直到20世紀90年代末期，當整個工業界從面向對象和軟體工程的幻影泡沫中走出來之後，才開始認真全面地審視軟體工藝的問題，而且通過敏捷運動、把軟體工藝的重要性和基本實踐提到了一個令人矚目的位置上。事實上，敏捷運動可以認為是軟體工藝的復興運動。此外，隨著《代碼大全2》、《軟體工藝》、《代碼閱讀》、《程式設計師修煉之道》等經典作品的出版，在技術圖書領域也陸續出現了一批專門探討軟體工藝的著作。這本《編程匠藝》也是這個領域中的一本佳作。
本書是一部全面討論軟體構造工藝實踐的著作，從軟體開發的計畫到架構設計，從編碼風格規範到軟體缺陷的檢測與管理，從程式設計師工具箱的配備到團隊協作精神的塑造，這本書都給予了翔實、風趣而具有啟發性的討論。這些討論，既有原則性、理論性一面，也有技術性的具體建議，對於團隊領導者、高級開發者和每一個希望快速進步的程式設計師具有明確的指導意義。如果讀者認同軟體工藝的重要性，那么可以說這本書是幫助讀者建構自己核心競爭力的一本難得的作品。特別值得一提的是，這本書中文版的翻譯流暢自然，在很多地方都體現出譯者的認真態度和翻譯功力。對於一本翻譯自英文的技術著作來說，這無疑是一個大大的加分。
當然，一本書的覆蓋面和功效畢竟是有限的，核心競爭力的確立和建構歸根到底是一個艱苦實踐的過程，不同性格的人也一定有著不同的目標和方式。但是我相信，對於有心人來說，只要我們不斷地探索和實踐，都會獲得自己的核心競爭力，做一個有準備的人，爭取和等待機會的垂青，最終實現自己的人生目標。
讀此書有感而發，借題發揮，是為評論。
孟 岩
《程式設計師》雜誌技術主編
2008年7月於北京
譯者序
作為從事軟體開發的程式設計師，你肯定遇到過這樣的情況：自認為完美的代碼，在項目快要結束的時候，卻總是會發現還有好多內容需要修改。更有甚者，由於人員的變動，那些他們遺留下來的“老代碼”，作為時間留給程式設計師與項目組的最大遺產，卻可能會成為項目組的災難。
除了受制於人類自身的缺陷之外，還有由於組織而帶來的問題，如客戶需求不斷變更、必須在有限的時間和預算之內完成項目，來自內部所謂“項目管理”的種種壓力，等等。天哪，這些問題我們絕大部分人都趕上了。
列寧曾在監獄中寫下了《怎么辦？》，指導了俄國的十月革命。而在軟體業，從一代宗師Frederick P. Brooks的《人月神話》開始，就在找“怎么辦”這個“銀彈”了。然而，“狼來了”在多次被喊出來後，已經很少有人相信了。我們必須承認，這些都是根本層面的問題，目前還不能得到解決。但是，本書的作者Pete Goodliffe認為，至少我們可以採取一些方式，減少一些開發上的痛苦。因為，除了開發，人生還有許多更為美好的事物在等著我們。我們這次也可以高喊“銀彈來了”。沒有最好，只有更好，誰知道這次不是真的呢？
著名國畫大師齊白石在年輕的時候，曾經做過木匠。據說有一次他和師傅去給地主幹活，在路上迎面走來另外一對木匠師徒。齊先生的師傅說，趕緊給別人讓路。師徒倆站在路邊，老師恭敬地目送那兩人漸漸走遠。齊白石不解，問師傅：同是木匠，你我師徒為什麼要給他們讓路。老師傅回頭說：為什麼？別人是做細活的，我們是做粗活的。
Pete Goodliffe在業界的年頭快要超過好多人的年齡了，此君曾經涉獵多個領域、不同的程式語言以及多種架構，並且曾經在採用不相同流程的公司里從事開發。在本書中，他把多年壓箱底的一些觀念想法和技巧告訴了大家，這些都是時間與智慧的結合，相信無論是開發人員、項目經理甚至測試人員，都可以從中發現阿里巴巴開啟金庫的鑰匙。
那么本書有什麼特色呢？對於想了解內容的普通讀者來說，本書至少有以下特點：
1．貼近實際 《編程匠藝——編寫卓越的代碼》是本書的書名，但也是作者的用心所在。人生有三個境界，最後一個就是“看山是山，看水是水”。這是廢話嗎？當然不是，作者對此給出了最好的解答。作為程式設計師，我們最喜歡爭論不同工具、平台、方法之間的優劣。而作者卻通過多年經驗，力圖告訴我們應該如何提高質量，並成為一名優秀的程式設計師。這些方法就像點石成金的手指，它們是方法論，而不是針對具體的工具或者平台的說教。我們現在所缺的，恰恰是這些能使自己更進一階的手段，而不是那些特殊的技術細節。
2．內容豐富翔實 很少有一本書能涵蓋如此多的領域，並且還如此紮實。作為一名程式設計師，我們可能永遠無法達到完美。而需要處於一種持續不斷地提高的狀態，總會有更多的東西需要學習。那么下一步應該做什麼呢？這裡就有答案。
3．可作為“秘要心法” 本書不僅適合入門者，也適合需要提高的開發人員，以及那些想管理好所謂代碼猴子的項目經理們。與《項目經理案頭手冊》一樣，這本書也將成為每人的案頭手冊或者枕邊書，可以作為應急或者提升的手段。如果以後碰到了問題，可以隨時參閱相關的章節。
4．心態決定一切 這句話對嗎？有了良好心態，不一定行，如果沒有，肯定不行。我們常常羨慕於老外以四五十歲的年紀仍然能繼續從事編程，為什麼我們不行呢？可能不同的讀者都會找到屬於自己的答案！Pete Goodliffe具有寬闊的視野，紮實的基礎，廣泛的愛好，帶有一種程式設計師應該具有的高雅和恬淡。這正是我們這個浮躁的時代中積極探索的一代程式設計師所不具備的。
最後禁不住要抱怨一下，作者Pete Goodliffe以他豐富的閱歷和愛好，給譯者帶來了不小的麻煩，比如出於對於音樂的愛好，所有章節的標題都來自英國的歌曲名稱。為了理解上的直觀，我們在翻譯的過程中採取的是“信達雅”中的“雅”，以保證國內讀者能很快切入主題。本書每章開始和行文的過程中，作者都引用了歷史上或者現在社會中一些名人的名言，這給翻譯增加了不少的難度，但是由於貼切精闢，這些名言也可稱為點睛之筆。尤為值得高興的是，此君對我中華文化竟然也有一定的造詣，孔夫子和老子的哲理名言竟然多次出現，而且能夠貼切地表達出這些聖人的思想對軟體開發有哪些啟示，這非常不簡單，難為了作者，也著實難為了譯者。從外國作者的筆下，讓我們著實體會到了自己國家的文化源遠流長。這從一個側面也體現出東海西海，千聖一心。
此書給了我們一個快速成功進階的好範例。我覺得它更像一個程式設計師的入門或者修行心法。從此入門，我們可以少走很多彎路。同時，我們也要爭取像佛經中“般若波羅密”所講的那樣：大智慧到彼岸，最後連佛法也像渡河的筏子一樣，成佛後立即丟棄。我更希望的是，看過此書的讀者們，最後能夠拍案而起，大聲說：我可以了。
譯 者
2007-12-2 於北京
前言
這就是《編程匠藝——編寫卓越的代碼》要達到的目的。這本書的內容也許從未有人向你傳授過：如何“在現實世界中”正確地編程。《編程匠藝——編寫卓越的代碼》填補了教科書中所缺少的內容。的確，這本書討論了優秀代碼的技術細節和難點。但除此之外它還包括更多的內容：如何以正確的方式編寫正確的代碼。
這是什麼意思呢？在現實世界中，編寫優秀的代碼有多重的含義：
編寫在技術上優雅的代碼 編寫可維護的代碼，讓其他人也可以看得懂 理解並改寫其他人所編寫的雜亂的代碼 與其他程式設計師良好地並肩工作
要成為一個編碼高手，你需要所有這些能力（甚至更多）。你必須理解代碼那神秘的生命：當你輸入代碼之後，會發生什麼？你必須擁有審美的能力：區分優美的代碼和醜陋的代碼。你還必須在實踐中運用理論的頭腦：認真思索並解決以下問題，什麼時候使用簡化的操作是合理的，什麼時候開始著手代碼設計，以及什麼時候停止和繼續（實用的“提前退出”原則）等。本書將幫助你實現這些目標。你將學習到如何在軟體工廠中求得生存，如何觀察戰場並了解敵人，如何制定戰術以避開敵人的陷阱，以及如何在種種困難中開發真正出色的程式。
軟體開發是一個有趣的職業。這個職業在迅猛地發展，充滿了瞬間即逝的流行元素與變幻莫測的風尚、致富的計畫以及新理念的傳播者。它並不成熟。我不是宣稱我有什麼神奇的答案，但我的確有一些來自經驗的、有用的建議與大家分享。本書沒有象牙塔中的理論，而僅僅是現實世界的經驗和一些好的習慣。
一旦消化了這本書的內容，你將不僅僅會成為一名更好的程式設計師，而且你將成為軟體工廠中一位更優秀的常住居民，一名真正的代碼戰士，你將學到編程匠藝的技藝。如果這聽起來並不令人激動，那么也許你應該考慮在軍隊里謀職了。
做得更好
那么，是什麼將“優秀”的程式設計師和“糟糕”的程式設計師區分開的呢？更重要的是，是什麼將“傑出”的程式設計師與僅僅是“夠格”的程式設計師區分開的呢？其秘密並不僅僅在於他們的技術能力——我曾經見過很多對語言標準瞭然於心、能夠寫出非常緊湊和讓人欣賞的C++程式的程式設計師，他們才華橫溢，但是他們寫出來的代碼卻非常糟糕。我也曾經見過更多謙遜的程式設計師，他們堅持編寫非常樸素的代碼，但是他們所編寫的程式卻非常優雅和縝密。
真正的區別是什麼？好的程式設計來自於你的態度。而好的態度在於你了解職業化的方法，以及對編寫最好的軟體的不懈追求，而不管軟體工廠的壓力有多大。態度就像一面透鏡，我們通過它來看世界。這面透鏡為我們的工作和行為增添了色彩。優秀的代碼需要由藝術大師精心編寫，而不是由懶散的程式設計師隨意地粗製濫造。通向優秀代碼的道路是由良好的意願鋪就成的。要成為傑出的程式設計師，我們必須學會從良好的意願起步，培養積極的看法，並使這種健康的態度發揚光大。
在本書中，我們將看到如何做到這一點。書中包含了大量的主題，小至實用的代碼編寫問題，大到組織架構性問題。在所有這些主題中，我都著重強調了什麼是正確的態度和方法。
態度——前進的角度
面對軟體開發的世界，隨著調查和分類的深入，我越來越相信使傑出的程式設計師脫穎而出的是態度。字典中對“態度”（attitude）的定義是這樣的：
態度
1．心態，看法：心理或感情的狀態；性情。
2．飛機姿勢，姿態：飛機軸相對於某一參照直線或平面（如地平線）所處
的位置。
第一個定義並沒有什麼令人意外之處，那么第二個呢？實際上，第二個定義比第一個更有揭示意義。
我們想像有三條貫穿飛機的軸線：一條從一側的機翼到另一側的機翼，一條從機頭到機尾，還有一條與前兩條軸線垂直相交於其交點處。飛行員靠這三條軸線來定位飛機，它們定義了飛機前行路線的角度。這稱為飛機的飛行姿態（attitude）。如果飛機的飛行姿態不正確，那么只要有很小的外力施加到飛機上，飛機就會極大地偏離它的目的地。飛行員必須時刻注視飛機的飛行姿態，特別是在起飛和著落等關鍵時刻。
雖然這聽起來像一個乏味的勵志片，但它確實是我們的軟體開發工作的一個貼切比喻。飛機的“態度”決定了它前進的角度，而我們的態度則決定了我們通往成功編碼之路的方向。程式設計師的技術能力有多強並不重要，如果他或她的能力沒有受到健康態度的支持，那么工作仍將是一件痛苦的差事。
錯誤的態度可以造成或中斷一個軟體項目，所以保持正確的前進角度來進行編程是至關重要的。你的態度要么阻礙，要么促進你的個人成長。要想成為更優秀的程式設計師，我們需要保證有正確的態度。
誰應該閱讀這本書
顯而易見，那些希望提高他們代碼質量的人應該讀這本書。我們都渴望成為更好的程式設計師；如果你沒有這種渴望，那么這本書就不適合你。你也許是一名職業的程式設計師，很可能已入行多年。你也許是一名高年級的學生，熟知編程的概念，但是不太肯定應該如何將這些概念付諸於實踐。如果你正在接受指導，或正在指導某個新手，讀這本書也會大有裨益。
你必須已經具有編程經驗。本書並不是要教你如何編程，而是告訴你如何更好地編程。當我盡力避免語言的歧義和教條時，我需要舉出一些代碼示例。這些示例大部分是使用C、C++或Java語言編寫的，因為這些語言是當今流行的語言體系。讀這些例子並不需要你是某種語言的專家，所以即使你不是一流的C++程式設計師，也不要惶恐。
我假設你作為本書的讀者，正在或者將要在軟體工廠的壓力下編寫代碼。這通常意味著你受僱於一個商業性的開發組織，但你有可能在開發一個混亂的開放源碼開發項目，或成為一個受僱為第三方提供軟體的槍手（項目承包方）。
本書包含哪些內容
本書的重點在於程式設計師的態度，但它絕不是一本心理學教科書。我們將深入探討許多主題，包括：
原始碼的樣式 防禦性的編碼技巧 如何有效地調試程式 良好的團隊合作技巧 管理你的原始碼
快速地瀏覽一下目錄，你就可以了解本書所包含的內容。選擇這些主題的理由是什麼呢？我曾有好多年從事培訓新程式設計師的工作，在此期間這些主題反反覆覆地被提出。我也曾在軟體工廠中任職多年，看到過很多一遍又一遍出現的問題，而這些問題都是與以上主題相關的。
如果你能夠征服這些編程的羈絆，那你將從一個學習編程的新手成長為一位真正的編碼高手。
本書的組織形式
我已經盡力將這本書寫得易於閱讀。傳統的格言這樣說，你應該從頭開始並努力工作到最後。忘掉這句話吧。你完全可以拿起這本書，打開你感興趣的章節，並從那裡讀起。每個章節都是獨立的，其中有很多有用的交叉引用，可以使你了解各章之間是如何結合在一起的。當然，如果你喜歡遵循傳統，從頭讀起也不失是一個好的選擇。
各個章節都以相似的結構編寫，你不會發現任何異樣。每一章都可以分為下面幾個部分：
本章主題
在每章的一開頭，我會列出該章的要點。你可以從這裡了解內容梗概。瀏覽一下這些主題，你就會知道將涉及哪些方面的內容。
章節主體
這裡都是會讓你感到本書物有所值的引人入勝的內容。
在章節主體中會時而出現一些“關鍵理念”。這些關鍵理念強調了重要的技巧、問題和態度，所以對這些內容要格外關注。其格式是這樣的：
關鍵概念 重要內容。注意！
總結
在每章的結尾，這一小節將總結該章所討論的主題。它為整章內容提供了一個概括性的視圖。如果你真的時間有限，也可以只閱讀每章的關鍵理念和這些總結部分。千萬別告訴別人這是我說的。
然後，我將對比優秀程式設計師和糟糕程式設計師的行為方式，來總結你應該力求採取的重要態度。如果你有勇氣，也可以根據這些例子來評價一下自己，但願事實不會讓你太傷心！
另請參見
這個列表會將你帶入相關的章節，並解釋它們是如何與當前的主題相關的。
思考
最後，我將列出一些需要思考的問題。這些問題並不游離於全書之外——它們是各章不可缺少的一部分。它們並不是要你回顧剛才所閱讀的主題，相反，這些問題的目的是使你進行思考，並聯想到該章之外的內容。這些問題分為兩組：
深入思考 這些問題將深入地研究各章的主題，並提出一些重要的論點。 了解自己 這些問題將探查你及軟體開發團隊的工作習慣和編碼成熟度。
不要略過這些問題！即使你很懶惰，以至於不想坐下來認真思考每個問題的答案（相信我，思考這些問題的答案會使你受益無窮的），至少也應該讀一讀這些問題並順便做些思考。
本書的最後一部分包含了對這些問題的答案和討論。這並不是一套直接的答案集——這些問題中很少可以直接用“是”或“否”來回答。在你思考並得到答案之後，不妨與我的答案做個比較。我的許多“答案”都包含了一些各章中未曾涉及的額外信息。
章節——詳細說明
本書的每一章都將討論一個單獨的主題，涉及現代軟體開發的一個具體問題領域。這些問題是人們編寫糟糕的代碼或糟糕地編寫代碼的常見原因。各章所描述的正確方法和態度，將使站在第一線的你生命力更旺盛。
本書共分為六篇；每一篇的目錄頁列出了各篇所包含的章節，並簡要描述了每個章節所包含的內容。這些篇將由內而外地展開討論。我們將從應當編寫“何種”代碼開始入手，最終著眼於我們應當“如何”編寫這種代碼。
我們的討論從代碼表面開始，主要是從巨觀的角度分析如何編寫原始碼。我特意將這部分放在全書的最前面，因為剪裁代碼是程式設計師們所真正關心的。
第1篇：代碼表面
本篇描述了開發原始碼的具體細節。我們將研究防禦性編程的技巧，以及如何編排代碼的格式和版式。然後，我們將繼續探討如何為代碼命名和做記錄。編寫注釋和處理錯誤的技巧也包含在本篇中。
第2篇：代碼的神秘生命
接下來，我們將討論編寫代碼的過程，即如何創建代碼和處理代碼。我們將了解構造代碼的工具、測試方法、調試技術、編譯可執行程式的正確過程以及最佳化等內容。最後，我們將思考如何寫出安全的程式。
第3篇：代碼的形成過程
然後，我們將從更廣泛的角度討論構造原始碼的問題。我們將討論代碼設計方案的開發、軟體的體系結構以及原始碼是如何隨時間而成長（或老化）的等問題。
下一步，我們將進入“巨觀”層面，抬起頭看看身邊發生的事——軟體工廠中的生活。如果不是一個開發小組的成員，我們是不可能寫出大規模軟體的，接下來的三篇包含了如何在團隊中獲益的技巧和方法。
第4篇：“一群”程式設計師
程式設計師不可能生活在真空中。（這需要有特殊的呼吸裝備。）在本篇中我們將進入更廣闊的世界，看一看好的開發習慣，以及如何將這些習慣融合到職業程式設計師的日常工作中。本篇還包含了良好的個人和團隊編程技巧，以及版本維護系統的使用方法。
第5篇：開發過程的組成部分
在本篇中，我們將描述軟體開發過程的一些規則：書寫規範、執行代碼審查以及時間預算的魔法。
第6篇：從高處鳥瞰
最後一篇將從高處向下審視開發過程，研究軟體開發方法論，以及不同的編程規則。
如何使用本書
從頭讀到尾，或從你感興趣的地方讀起，都沒問題。
重要的是，你要帶著一種開闊的思維去讀《編程匠藝——編寫卓越的代碼》這本書，並思考如何將你所讀到的內容套用到你所做的事情上。聰明的人從自己的錯誤中學習，而更聰明的人則從別人的錯誤中學習。從別人的經驗中學習總是有益的，所以在讀過這本書之後，就可以詢問你所尊敬的程式設計師的看法。瀏覽各章之後的問題並與這些程式設計師進行討論。
希望你在學習編碼匠藝的時候，能夠得到快樂。讀過之後，回顧一下，看看有多少匠藝是你願意接受的，你的匠藝提高了多少，以及你的態度是否有所改進。如果什麼也沒有發生，那么這本書就失敗了。我相信結果不會是這樣的。
給導師的一點建議
這是一本指導經驗較少的程式設計師的很好的工具書。對於這一點，我在撰寫本書的過程中特別進行了考慮，並且本書已證明有助於提高程式設計師的成熟度和洞察力。
讀本書的最佳方式，並不是用某種方法一口氣學完所有內容。相反，最佳方式應該是分別閱讀各章，然後與接受你指導的新手討論該章的內容。各章最後列出的問題可以作為討論的起點，所以從這些問題開始討論，不失為一個好辦法。
目錄
第1篇 代碼表面第一部分
第1章 善於防守：健壯代碼的防禦性編程技巧 3
1.1 向優秀的代碼前進 3
1.2 構想：最壞的選擇 4
1.3 什麼是防禦性編程？ 6
1.4 又大又壞的世界 8
1.5 防禦性編程技巧 9
1.5.1 使用好的編碼風格和合理的設計 9
1.5.2 不要倉促地編寫代碼 9
1.5.3 不要相信任何人 10
1.5.4 編碼的目標是清晰，而不是簡潔 11
1.5.5 不要讓任何人做他們不該做的修補工作 11
1.5.6 編譯時打開所有警告開關 12
1.5.7 使用靜態分析工具 13
1.5.8 使用安全的數據結構 13
1.5.9 檢查所有的返回值 14
1.5.10 審慎地處理記憶體（和其他寶貴的資源） 14
1.5.11 在聲明位置初始化所有變數 15
1.5.12 儘可能推遲一些聲明變數 15
1.5.13 使用標準語言工具 15
1.5.14 使用好的診斷信息日誌工具 16
1.5.15 審慎地進行強制轉換 16
1.5.16 細則 16
1.6 約束 17
1.6.1 約束的內容 19
1.6.2 移除約束 19
1.7 總結 22
1.8 另請參見 22
1.9 思考 24
1.9.1 深入思考 24
1.9.2 結合自己 24
第2章 精心布局：原始碼的版面和樣式 26
2.1 什麼是關鍵 27
2.2 了解你的讀者 27
2.3 什麼是好的樣式 29
2.4 使用括弧 30
2.4.1 K&R括弧風格 30
2.4.2 懸掛式的括弧風格 31
2.4.3 縮進的括弧風格 32
2.4.4 其他的括弧風格 33
2.5 主宰一切的風格 33
2.6 內部風格（以及在哪裡使用它們） 35
2.7 設立標準 37
2.8 正義的戰爭 39
2.9 總結 40
2.10 另請參見 42
2.11 思考 42
2.11.1 深入思考 42
2.11.2 結合自己 43
第3章 名正言順：為有意義的事物起有意義的名稱 45
3.1 為什麼我們應該恰當地命名呢 47
3.2 我們對什麼進行命名 47
3.3 名字遊戲 48
3.3.1 描述性 48
3.3.2 技術上正確 48
3.3.3 符合語言習慣 49
3.3.4 恰當 49
3.4 具體細節 50
3.4.1 命名變數 51
3.4.2 命名函式 52
3.4.3 命名類型 53
3.4.4 命名名字空間 54
3.4.5 命名宏 55
3.4.6 命名檔案 56
3.5 玫瑰不叫玫瑰 57
3.5.1 保持前後一致 58
3.5.2 利用上下文 58
3.5.3 使用對你有利的名稱 59
3.6 總結 59
3.7 另請參見 61
3.8 思考 62
3.8.1 深入思考 62
3.8.2 結合自己 63
第4章 不言自明：編寫“自文檔化”代碼的技巧 64
4.1 自文檔化的代碼 66
4.2 編寫自文檔化代碼的技術 69
4.2.1 使用好的樣式編寫簡單的代碼 69
4.2.2 選擇有意義的名稱 70
4.2.3 分解為原子函式 70
4.2.4 選擇描述性的類型 71
4.2.5 命名常量 71
4.2.6 強調重要的代碼 72
4.2.7 分組相關信息 72
4.2.8 提供檔案頭 72
4.2.9 恰當地處理錯誤 73
4.2.10 編寫有意義的注釋 73
4.3 實用的自文檔化方法 74
4.3.1 文學性編程 74
4.3.2 文檔化工具 76
4.4 總結 78
4.5 另請參見 79
4.6 思考 79
4.6.1 深入思考 79
4.6.2 結合自己 81
第5章 隨篇注釋：如何編寫代碼注釋 82
5.1 什麼是代碼注釋 83
5.2 注釋看上去是什麼樣的 84
5.3 多少注釋是恰當的 84
5.4 注釋中應該有些什麼 85
5.4.1 解釋為什麼，而不是怎么樣 85
5.4.2 不要描述代碼 86
5.4.3 不要取代代碼 86
5.4.4 確保注釋有用 86
5.4.5 避免分心 88
5.5 實踐 88
5.6 從審美的角度看注釋 89
5.6.1 一致性 89
5.6.2 清晰的塊注釋 90
5.6.3 縮進的注釋 90
5.6.4 行章節附注釋 91
5.6.5 幫助你閱讀代碼 91
5.6.6 選擇一種維護成本較低的風格 92
5.6.7 分隔板 92
5.6.8 標誌 92
5.6.9 檔案頭注釋 93
5.7 使用注釋 94
5.7.1 幫助你編寫例行程式 94
5.7.2 錯誤修正通告 95
5.7.3 注釋過時 95
5.7.4 維護和空洞無物的注釋 96
5.8 總結 97
5.9 另請參見 98
5.10 思考 98
5.10.1 深入思考 98
5.10.2 結合自己 99
第6章 人非聖賢：處理不可避免的情況——代碼中的錯誤情形 100
6.1 從何而來 101
6.2 錯誤報告機制 102
6.2.1 不報告 103
6.2.2 返回值 103
6.2.3 錯誤狀態變數 104
6.2.4 異常 104
6.2.5 信號 106
6.3 檢測錯誤 107
6.4 處理錯誤 108
6.4.1 何時處理錯誤 109
6.4.2 可能的反應 110
6.4.3 代碼示例 112
6.5 使地獄浮現 116
6.6 管理錯誤 118
6.7 總結 119
6.8 另請參見 119
6.9 思考 120
6.9.1 深入思考 120
6.9.2 結合自己 121
第2篇 代碼的神秘生命第一部分
第7章 欲善其事，先利其器：使用工具構建軟體 125
7.1 什麼是軟體工具 126
7.2 為什麼要在意工具 128
7.3 使工具發揮作用 129
7.3.1 了解它能做些什麼 130
7.3.2 學習如何駕馭它 130
7.3.3 了解它適合什麼任務 131
7.3.4 檢查它是否可用 131
7.3.5 找到了解更多信息的途徑 131
7.3.6 查明新版本何時出現 132
7.4 哪個工具 132
7.4.1 原始碼編輯工具 133
7.4.2 代碼構建工具 136
7.4.3 調試和調查工具 138
7.4.4 語言支持工具 140
7.4.5 其他工具 141
7.5 總結 142
7.6 另請參見 143
7.7 思考 144
7.7.1 深入思考 144
7.7.2 結合自己 145
第8章 測試時代：測試代碼的魔術 146
8.1 反思現實 148
8.2 誰、是什麼、何時以及為什麼 149
8.2.1 我們為什麼要測試 149
8.2.2 誰來進行測試 150
8.2.3 測試的內容有些什麼 150
8.2.4 何時進行測試 151
8.3 測試並不難…… 152
8.4 測試的類型 156
8.5 選擇單元測試用例 160
8.6 為測試而設計 163
8.7 看！不要用手 164
8.8 面對故障該怎么辦 165
8.9 你能管理它嗎 166
8.9.1 缺陷跟蹤系統 166
8.9.2 bug審查 168
8.10 總結 169
8.11 另請參見 169
8.12 思考 170
8.12.1 深入思考 170
8.12.2 結合自己 171
第9章 尋找缺陷（調試）：當事情進展得不順利時該怎么辦 172
9.1 生活的真相 173
9.2 bug的種類 174
9.2.1 從遠處看 174
9.2.2 從近處看 175
9.2.3 從更近處看 178
9.3 消滅害蟲 180
9.3.1 地下之路 181
9.3.2 地上之路 181
9.4 搜尋bug 182
9.4.1 編譯時錯誤 182
9.4.2 運行時錯誤 184
9.5 如何修正缺陷 188
9.6 預防 190
9.7 除蜂劑、驅蟲劑、捕蠅紙 190
9.7.1 調試器 190
9.7.2 記憶體訪問校驗器 191
9.7.3 系統調用跟蹤 191
9.7.4 核心轉儲 191
9.7.5 日誌 191
9.8 總結 192
9.9 另請參見 193
9.10 思考 194
9.10.1 深入思考 194
9.10.2 結合自己 194
第10章 代碼構建：將原始碼轉換為可執行代碼的過程 196
10.1 語言障礙 197
10.1.1 解釋型語言 198
10.1.2 編譯型語言 199
10.1.3 位元組編譯型語言 200
10.2 小題大做 201
10.3 構建軟體版本 203
10.4 怎樣才算是一個優秀的構建系統 206
10.4.1 簡潔 206
10.4.2 一致 207
10.4.3 可重複和可靠 207
10.4.4 原子性 208
10.4.5 能夠應付錯誤 209
10.5 技術細節 210
10.5.1 目標的選擇 210
10.5.2 內務處理 212
10.5.3 依賴關係 212
10.5.4 自動構建 213
10.5.5 構建配置 214
10.5.6 遞歸地使用make 215
10.6 請發布我吧 215
10.7 構建大師是全能的嗎 218
10.8 總結 218
10.9 另請參見 219
10.10 思考 219
10.10.1 深入思考 220
10.10.2 結合自己 220
第11章 追求速度：最佳化程式和編寫高效的代碼 222
11.1 最佳化是什麼 223
11.2 是什麼使代碼不盡如人意 224
11.3 為什麼不進行最佳化呢 225
11.4 為什麼要進行最佳化 228
11.5 最佳化的具體細節 229
11.5.1 證明你需要進行最佳化 230
11.5.2 找出運行得最慢的代碼 230
11.5.3 測試代碼 232
11.5.4 最佳化代碼 233
11.5.5 最佳化之後 233
11.6 最佳化的技術 233
11.6.1 設計更改 234
11.6.2 代碼更改 237
11.7 編寫高效的代碼 241
11.8 總結 243
11.9 另請參見 244
11.10 思考 244
11.10.1 深入思考 244
11.10.2 結合自己 245
第12章 不安全感綜合徵：編寫安全的程式 247
12.1 危險 248
12.2 敵人 250
12.3 藉口，都是藉口 252
12.4 感到很脆弱 253
12.4.1 不安全的設計和體系結構 253
12.4.2 緩沖溢出 254
12.4.3 嵌入的查詢字元串 255
12.4.4 競爭狀況 255
12.4.5 整數溢出 256
12.5 防範措施 257
12.5.1 系統安裝技術 258
12.5.2 軟體設計技術 258
12.5.3 代碼實現技術 260
12.5.4 規程技術 261
12.6 總結 261
12.7 另請參見 262
12.8 思考 263
12.8.1 深入思考 263
12.8.2 結合自己 263
第3篇 代碼的形成過程第一部分
第13章 崇尚設計：如何創作出優秀的軟體設計 267
13.1 邊設計邊編程 268
13.2 我們要設計什麼 269
13.3 為什麼這么忙亂 270
13.4 良好的軟體設計 271
13.4.1 簡潔 272
13.4.2 優雅 273
13.4.3 模組化 274
13.4.4 良好的接口 275
13.4.5 可擴展性 278
13.4.6 避免重複 278
13.4.7 可移植性 279
13.4.8 符合語言習慣 280
13.4.9 良好地文檔化 280
13.5 如何設計代碼 280
13.5.1 設計方法和過程 281
13.5.2 設計工具 282
13.6 總結 285
13.7 另請參見 285
13.8 思考 286
13.8.1 深入思考 286
13.8.2 結合自己 287
第14章 軟體體系結構：奠定軟體設計的基礎 288
14.1 什麼是軟體體系結構 289
14.1.1 軟體藍圖 289
14.1.2 視圖 290
14.1.3 在何時和何處進行體系結構設計 292
14.1.4 用體系結構來做什麼 293
14.1.5 關於組件和連線 294
14.2 什麼是良好的體系結構 295
14.3 體系結構風格 297
14.3.1 沒有體系結構 297
14.3.2 分層的體系結構 298
14.3.3 管道和過濾器體系結構 299
14.3.4 客戶端/伺服器體系結構 299
14.3.5 基於組件的體系結構 302
14.3.6 框架 303
14.4 總結 303
14.5 另請參見 304
14.6 思考 305
14.6.1 深入思考 305
14.6.2 結合自己 305
第15章 改良與革命：代碼是如何成長的 307
15.1 軟體腐爛 308
15.2 警告信號 310
15.3 代碼是如何成長的 312
15.4 相信不可能之事 315
15.5 對此我們可以做些什麼？ 316
15.5.1 編寫新代碼 316
15.5.2 維護現有代碼 317
15.6 總結 319
15.7 另請參見 319
15.8 思考 320
15.8.1 深入思考 321
15.8.2 結合自己 321
第4篇 “一群”程式設計師第一部分
第16章 代碼猴子：培養正確的編程態度和方法 325
16.1 各種各樣的猴子 326
16.1.1 賣力工作的程式設計師 327
16.1.2 代碼猴子 328
16.1.3 權威 329
16.1.4 半權威 330
16.1.5 傲慢的天才 331
16.1.6 牛仔 333
16.1.7 規劃者 334
16.1.8 老前輩 335
16.1.9 狂熱者 336
16.1.10 單線條程式設計師 337
16.1.11 拖沓者 338
16.1.12 勉強的團隊領導 339
16.1.13 你 340
16.2 理想的程式設計師 340
16.3 那么該怎么辦 341
16.4 最愚蠢的人 342
16.5 總結 343
16.6 另請參見 343
16.7 行為表格 344
16.8 思考 345
16.8.1 深入思考 345
16.8.2 結合自己 345
第17章 團結就是力量：團隊合作與個人程式設計師 347
17.1 我們的團隊——概覽 348
17.2 團隊組織 350
17.2.1 管理方法 350
17.2.2 責任劃分 350
17.2.3 組織和代碼結構 352
17.3 團隊合作工具 352
17.4 團隊疾病 354
17.4.1 巴別塔 354
17.4.2 獨裁制 356
17.4.3 民主制 357
17.4.4 衛星站 359
17.4.5 大峽谷 361
17.4.6 流沙 363
17.4.7 旅鼠 365
17.5 良好團隊合作的個人技巧和特點 366
17.5.1 溝通 366
17.5.2 謙虛 367
17.5.3 處理衝突 367
17.5.4 學習和適應能力 369
17.5.5 了解你的不足之處 369
17.6 團隊合作原則 370
17.6.1 集體代碼所有制 370
17.6.2 尊重別人的代碼 371
17.6.3 編碼準則 371
17.6.4 定義成功 371
17.6.5 定義責任 372
17.6.6 避免倦怠 372
17.7 團隊的生命周期 372
17.7.1 團隊的創建 373
17.7.2 團隊的成長 375
17.7.3 團隊合作 377
17.7.4 團隊結束 377
17.8 總結 380
17.9 另請參見 381
17.10 行為表格 382
17.11 思考 383
17.11.1 深入思考 383
17.11.2 結合自己 383
第18章 安全措施：原始碼控制與自我控制 385
18.1 我們的責任 386
18.2 原始碼控制 387
18.2.1 修訂控制 388
18.2.2 訪問控制 390
18.2.3 處理代碼庫 390
18.2.4 在代碼樹上創建分支 391
18.2.5 原始碼控制簡史 393
18.3 配置管理 393
18.4 備份 395
18.5 發布原始碼 396
18.6 應該將原始碼放在哪裡 397
18.7 總結 398
18.8 另請參見 399
18.9 思考 400
18.9.1 深入思考 400
18.9.2 結合自己 400
第5篇 開發過程的組成部分第一部分
第19章 注意細節：編寫軟體規範 403
19.1 規範到底是什麼 404
19.2 規範的類型 405
19.2.1 需求規範 407
19.2.2 功能規範 409
19.2.3 系統體系結構規範 410
19.2.4 用戶界面規範 410
19.2.5 設計規範 411
19.2.6 測試規範 412
19.3 規範應當包含哪些內容 413
19.4 規範編寫過程 415
19.5 我們為什麼會不編寫規範 418
19.6 總結 420
19.7 另請參見 420
19.8 思考 421
19.8.1 深入思考 421
19.8.2 結合自己 421
第20章 代碼審查：執行代碼審查 423
20.1 什麼是代碼審查 424
20.2 何時進行審查 425
20.2.1 是否要進行審查 426
20.2.2 審查哪些代碼 427
20.3 執行代碼審查 427
20.3.1 代碼審查會議 428
20.3.2 集成審查 431
20.4 審查你的態度 432
20.4.1 作者的態度 432
20.4.2 審查人員的態度 433
20.5 完美的代碼 434
20.6 代碼審查之外 435
20.7 總結 436
20.8 另請參見 436
20.9 清單 437
20.10 思考 438
20.10.1 深入思考 438
20.10.2 結合自己 438
第21章 時間估計：軟體時間範圍估計的魔術 439
21.1 在黑暗中摸索 440
21.2 為什麼估計這么困難 441
21.3 壓力之下 443
21.4 實用的估計方法 444
21.5 計畫遊戲 447
21.6 堅持 451
21.7 總結 454
21.8 另請參見 454
21.9 思考 455
21.9.1 深入思考 455
21.9.2 結合自己 455
第6篇 從高處鳥瞰第一部分
第22章 程式秘方：代碼開發的方法和過程 459
22.1 編程風格 460
22.1.1 結構化編程 461
22.1.2 面向對象的程式設計 462
22.1.3 函式式編程 463
22.1.4 邏輯編程 464
22.2 烹飪方法：做什麼與怎樣做 464
22.3 開發過程 465
22.3.1 混亂 466
22.3.2 瀑布模型 468
22.2.3 SSADM和PRINCE 470
22.3.4 V模型 470
22.3.5 原型設計 471
22.3.6 疊代和增量開發 472
22.3.7 螺鏇模型 473
22.3.8 敏捷的方法 474
22.3.9 其他開發過程 475
22.4 已經夠了 476
22.5 選擇一種過程 477
22.6 總結 478
22.7 另請參見 478
22.8 思考 479
22.8.1 深入思考 479
22.8.2 結合自己 479
第23章 編程領域大觀：不同的編程分支 481
23.1 應用程式編程 482
23.1.1 塑裝軟體 483
23.1.2 定製應用程式 484
23.2 遊戲編程 485
23.3 系統編程 486
23.4 嵌入式編程 488
23.5 分散式編程 490
23.6 網路應用程式編程 492
23.7 企業編程 494
23.8 數字編程 495
23.9 那又怎樣 497
23.10 總結 497
23.11 另請參見 498
23.12 思考 498
23.12.1 深入思考 499
23.12.2 結合自己 499
第24章 下一步呢：結果好就一切都好 500
但下一步該做什麼呢？ 501
答案和討論 504
參考書目 607
