讀后感

《代碼大全》是一本指導(dǎo)“代碼構(gòu)建”的書，指導(dǎo)我們?nèi)绾螌懗鰞?yōu)秀的代碼,，如何成為優(yōu)秀的程序員,。

這樣一本900多頁的大部頭書，當(dāng)我們基于既往的編程經(jīng)驗(yàn),，在讀每一個(gè)部分,，每一個(gè)章節(jié)的時(shí)候，往往會(huì)對(duì)作者對(duì)軟件構(gòu)建的認(rèn)知和思想,，具體的,、可操作的解決問題的辦法及原因，由衷的理解和認(rèn)同,，感覺“就是應(yīng)該這么做”,。

這像一本定義“規(guī)范”的書，我們很容易就理解了,，但是想完全按照它定義的來做的時(shí)候,，大多數(shù)卻忘記了。

當(dāng)我囫圇吞棗一樣,，盡快的挑選著讀了一部分的時(shí)候,，和一些同事談起這個(gè)問題的時(shí)候,，曾經(jīng)的看法是，這本書是需要重復(fù)讀的,，可能無法記住所有的規(guī)則,，但是它對(duì)人的影響是潛移默化的。

后來又想,，這個(gè)“潛移默化”肯定是有的,，也是好的，但是僅僅靠“潛移默化”,，可能還是處于一個(gè)低層次,。

當(dāng)我們無法準(zhǔn)確講出規(guī)范的時(shí)候，怎么能信心十足的讓它指導(dǎo)我們的工作,？

當(dāng)團(tuán)隊(duì)協(xié)作的時(shí)候,，無法用對(duì)規(guī)范的準(zhǔn)確描述，用引經(jīng)據(jù)典的出處,，說服別人,，如何在協(xié)作中教育別人，提高團(tuán)隊(duì)水平?

所以,，還是需要領(lǐng)會(huì),，并記住。那么,，如何做到這一點(diǎn)呢,？

首先，思考一下,，為什么那么易忘,，除了重復(fù)度不夠之外，更重要的原因似乎是方法出了問題,。讀了很多個(gè)章節(jié)（軟件構(gòu)建中的思想和規(guī)則）,，也就是在《代碼大全》的世界里，有了很多個(gè)點(diǎn),，但沒有把這些點(diǎn)從宏觀上串起來,，也就是沒有形成面，所謂“皮之不存,，毛將焉附”,，沒有骨架，血肉是附著不上去的,，特別容易就掉下來,。

所以，需要從宏觀上,，從整體上,，理解,、記住《代碼大全》對(duì)于軟件構(gòu)建所定義的骨架，然后把每個(gè)章節(jié)的血肉附著上去,，才能結(jié)實(shí)的組裝起來,，才不容易忘記。

這是一本值得沒事的時(shí)候,，就翻翻的書,，技術(shù)的浪潮洶涌先前，編程的技法變幻莫測(cè),，有些書可以在非常非常長的時(shí)間內(nèi)指導(dǎo)我們的工作,，不褪色，《代碼大全》就是這樣一本書,。

年輕時(shí)學(xué)過很多編程語言,，大學(xué)里的Turbo C，工作中開始的ASP,、VB,、DELPHI、C++ Builder,，到后來相當(dāng)長的時(shí)間里使用C#,，再到近幾年使用Java，學(xué)習(xí)的Ruby,，一直在變換著編程的技法，不是沒有遇到過高人,，實(shí)在是自己的悟性太慢,，沒有領(lǐng)會(huì)編程的真諦，并把大把的青春浪費(fèi)在游戲上,，浪費(fèi)在編程無關(guān)的方面,。

編程的技法，固然重要,，需要熟練,，并能快速解決問題；但編程真正重要的東西,，是思想和境界,，是數(shù)據(jù)結(jié)構(gòu)，是并發(fā),，之后可以是基礎(chǔ)框架,；編程的進(jìn)步，來源于多寫高質(zhì)量的代碼,，最好能參與開源工程并貢獻(xiàn)代碼,，也來源于多總結(jié),，比如寫技術(shù)文章。

Java生態(tài),，我們可以看這樣幾本書：《Java編程思想》、《深入理解Java虛擬機(jī)》,、《Spring3.0企業(yè)應(yīng)用開發(fā)指南》,、《Spring Internals》、《Java與模式》,，并熟練使用Linux,，Java容器，Java IDE工具,；看書的過程,，學(xué)習(xí)的過程，都不是一蹴而就的,，要有足夠的耐心,，投入充足的時(shí)間，三年有小成,，五年可以進(jìn)入專家行列,。所以，在這么長的時(shí)間里,，一定是自驅(qū)動(dòng)的,，興趣驅(qū)動(dòng)的，沒有興趣,，是很難很難持續(xù)這么長時(shí)間的,。

骨架

《代碼大全》全書900多頁，分為5個(gè)部分,，35個(gè)章節(jié),。

第一部分，“打好基礎(chǔ)”

分為4個(gè)章節(jié),，分別介紹了軟件構(gòu)建在軟件開發(fā)中的地位,，用現(xiàn)實(shí)中比較容易理解的問題類比軟件研發(fā)（目的是更容易理解），前期充分準(zhǔn)備的重要和必要性,，如何對(duì)軟件構(gòu)建使用的語言,、規(guī)范、框架等進(jìn)行決策,。

第二部分,，“創(chuàng)建高質(zhì)量的代碼”

基礎(chǔ)打好了（需求、產(chǎn)品,、架構(gòu)）,，開始進(jìn)入軟件構(gòu)建的世界,，從設(shè)計(jì)、類,、子程序,、編程方法角度，告訴我們?nèi)绾蝿?chuàng)造高質(zhì)量的代碼,。

第5章：軟件構(gòu)建中得設(shè)計(jì),；第6章：可以工作的類；第7章：高質(zhì)量的子程序,；第8章：防御式編程,；第9章：偽代碼編程過程。

第三部分,，變量

從整體角度領(lǐng)會(huì)如何創(chuàng)建高質(zhì)量的代碼之后,，開始進(jìn)入構(gòu)建的細(xì)節(jié)，首先從變量開始,。

第10章：使用變量的一般事項(xiàng),，告訴我們?cè)趺从米兞浚热绯跏蓟?、作用域等?/p>

第11章：變量名的力量,，本章是變量命名規(guī)范，告訴我們?cè)趺磳?duì)變量命名,；

第12章：基本數(shù)據(jù)類型,；

第13章：不常見的數(shù)據(jù)類型；

大部分公司的“編程規(guī)范”,，都會(huì)對(duì)變量名進(jìn)行部分約束,，如果和本書沖突，應(yīng)該先按照公司當(dāng)前規(guī)定的來執(zhí)行,，并逐步推進(jìn)成最好的方式。

第四部分,，語句

組織語句,，貫穿著構(gòu)建的過程，這一部分先略過,。

第14章：組織直線型代碼,；

第15章：使用條件語句；

第16章：控制循環(huán),；

第17章：不常見的控制結(jié)構(gòu),；

第18章：表驅(qū)動(dòng)法；

第19章：一般控制問題,。

第五部分,，代碼改善

代碼的改善,，是一個(gè)貫穿整個(gè)軟件生命周期的過程。開發(fā)者測(cè)試,、調(diào)試,、重構(gòu)、調(diào)整,，都是很必要的技法,。

第20章：軟件質(zhì)量概述；

第21章：協(xié)同構(gòu)建,，本章描述的結(jié)對(duì)構(gòu)建,，可以僅當(dāng)做一種思想，不具備現(xiàn)實(shí)操作性,；

第22章：開發(fā)者測(cè)試,；

第23章：調(diào)試；

第24章：重構(gòu),；

第25章：代碼調(diào)整策略 ,；

第26章：代碼調(diào)整技術(shù)。

第六部分,，系統(tǒng)考慮

第27章：程序規(guī)模對(duì)構(gòu)建的影響,；

第28章：管理構(gòu)建；

第29章：集成,；

第30章：編程工具,。

第七部分，軟件工藝

第31章：布局與風(fēng)格,；

第32章：自說明代碼,；

第33章：個(gè)人性格；

第34章：軟件工藝的話題,；

第35章：何處有更多信息,。

第一部分：打好基礎(chǔ)

Laying the Foundation

第1章 歡迎進(jìn)入軟件構(gòu)建的世界

Welcome to Software Construction

Key Points

軟件構(gòu)建是軟件開發(fā)的核心活動(dòng)：構(gòu)建活動(dòng)是每個(gè)項(xiàng)目中唯一一項(xiàng)必不可少的工作。

軟件構(gòu)建的主要活動(dòng)包括：詳細(xì)設(shè)計(jì),、編碼,、調(diào)試、集成,、開發(fā)者測(cè)試（developer testing）（包括單元測(cè)試和集成測(cè)試）,。

構(gòu)建也長被稱作“編碼”和“編程”。

構(gòu)建活動(dòng)的質(zhì)量對(duì)軟件的質(zhì)量有著實(shí)質(zhì)性的影響,。

最后,，你對(duì)“如何進(jìn)行構(gòu)建”的理解程度，決定了你這名程序員的優(yōu)秀程度--這就是本書其余部分的主題了。

第2章 用隱喻來更充分地理解軟件開發(fā)

Metaphors for a Richer Understanding of Software Development

Key Points

隱喻是啟示而不是算法,。因此它們往往有一點(diǎn)隨意（sloppy）,。

隱喻把軟件開發(fā)過程與其他你熟悉的活動(dòng)聯(lián)系在一起，幫助你更好地理解,。

有些隱喻比其他一些隱喻更貼切,。

通過把軟件的構(gòu)建過程比作是房屋的建設(shè)過程，我們可以發(fā)現(xiàn),，仔細(xì)的準(zhǔn)備是必要的,，而大型項(xiàng)目和小型項(xiàng)目之間也是有差異的。

通過把軟件開發(fā)中的實(shí)踐比作是智慧工具箱中的工具,，我們又發(fā)現(xiàn),，每位程序員都有許多工具，但并不存在任何一個(gè)能適用于所有工作的工具,，因地制宜地選擇正確工具是成為能有效編程的程序員的關(guān)鍵,。

不同的隱喻彼此并不排斥，應(yīng)當(dāng)使用對(duì)你最有益處的某種隱喻組合,。

第3章 三思而后行：前期準(zhǔn)備

Measure Twice, Cut Once: Upstream Prerequisites

Key Points

構(gòu)建活動(dòng)的準(zhǔn)備工作的根本目標(biāo)在于降低風(fēng)險(xiǎn),。要確認(rèn)你的準(zhǔn)備活動(dòng)是在降低風(fēng)險(xiǎn)，而非增加風(fēng)險(xiǎn),。

如果你想開發(fā)高質(zhì)量的軟件,，軟件開發(fā)過程必須由始至終關(guān)注質(zhì)量。在項(xiàng)目初期關(guān)注質(zhì)量,，對(duì)產(chǎn)品質(zhì)量的正面影響比在項(xiàng)目末期關(guān)注質(zhì)量的影響要大,。

程序員的一部分工作是教育老板和合作者，告訴他們軟件開發(fā)過程,，包括在開始編程之前進(jìn)行充分準(zhǔn)備的重要性,。

你所從事的軟件項(xiàng)目的類型對(duì)構(gòu)建活動(dòng)的前期準(zhǔn)備有重大影響--許多項(xiàng)目應(yīng)該是高度迭代式的，某些應(yīng)該是序列式的,。

如果沒有明確的問題定義,，那么你可能會(huì)在構(gòu)建期間解決錯(cuò)誤的問題。

如果沒有做完良好的需求分析工作,，你可能沒能察覺待解決的問題的重要細(xì)節(jié),。如果需求變更發(fā)生在構(gòu)建之后的階段，其代價(jià)是“在項(xiàng)目早期更改需求”的20至100倍,。因此在開始編程之前，你要確認(rèn)“需求”已經(jīng)到位了,。

如果沒有做完良好的架構(gòu)設(shè)計(jì),，你可能會(huì)在構(gòu)建期間用錯(cuò)誤的方法解決正確的問題。架構(gòu)變更的代價(jià)隨著“為錯(cuò)誤的架構(gòu)編寫的代碼數(shù)量”增加而增加，因此,，也要確認(rèn)“架構(gòu)”已經(jīng)到位了,。

理解項(xiàng)目的前期準(zhǔn)備所采用的方法，并相應(yīng)地選擇構(gòu)建方法,。

第4章 關(guān)鍵的“構(gòu)建”決策

Key Construction Decisions

Key Points

每種編程語言都有其優(yōu)點(diǎn)和弱點(diǎn),。要知道你使用的語言的明確優(yōu)點(diǎn)和弱點(diǎn)。

在開始編程之前,，做好一些約定（convertion）,。“改變代碼使之符合這些約定”是近乎不可能的,。

“構(gòu)建的實(shí)踐方法”的種類比任何單個(gè)項(xiàng)目能用到的要多,。有意識(shí)地選擇最適合你的項(xiàng)目的實(shí)踐方法。

問問你自己,，你采用的編程實(shí)踐是對(duì)你所用的編程語言的正確響應(yīng),，還是受它的控制？請(qǐng)記得“深入一種編程語言”,，不要僅“在一種語言上編程”,。

你在技術(shù)浪潮中的位置決定了哪種方法是有效的--甚至是可能用到的。確定你在技術(shù)浪潮中的位置,，并相應(yīng)調(diào)整計(jì)劃和預(yù)期目標(biāo),。

第二部分：創(chuàng)建高質(zhì)量的代碼

Creating High-Quality Code

第5章 軟件構(gòu)建中的設(shè)計(jì)

Design in Construction

Key Points

軟件的首要技術(shù)使命就是管理復(fù)雜度。以簡單性作為努力工作的設(shè)計(jì)方案對(duì)此最有幫助,。

簡單性可以通過兩種方式來獲?。阂皇菧p少在同一時(shí)間所關(guān)注的本質(zhì)性復(fù)雜度的量，而是避免生成不必要的偶然的復(fù)雜度,。

設(shè)計(jì)是一種啟發(fā)式的過程,。固執(zhí)于某一種單一方法會(huì)損害創(chuàng)新能力，從而損害你的程序,。

好的設(shè)計(jì)都是迭代的,。你嘗試設(shè)計(jì)的可能性越多，你的最終設(shè)計(jì)方案就會(huì)變得越好,。

信息隱藏是個(gè)非常有價(jià)值的概念,。通過詢問“我應(yīng)該隱藏些什么？”能夠解決很多困難的設(shè)計(jì)問題,。

很多有用有趣的,、關(guān)于設(shè)計(jì)的信息存在于本書之外。這里所給出的觀點(diǎn)只是對(duì)這些有價(jià)值資源的一點(diǎn)提示而已,。

第6章 可以工作的類

Working Classes

Key Points

類的接口應(yīng)提供一致的抽象,。很多問題都是由于違背該原則而引起的,。

類的接口應(yīng)隱藏一些信息--如某個(gè)系統(tǒng)接口、某項(xiàng)設(shè)計(jì)決策,、或一些實(shí)現(xiàn)細(xì)節(jié),。

包含往往比繼承更為可取--除非你要對(duì)“是一個(gè)/is a”的關(guān)系建模。

繼承是一種有用的工具,，但它卻會(huì)增加復(fù)雜度,，這有違于軟件的首要技術(shù)使命--管理復(fù)雜度。

類是管理復(fù)雜度的首選工具,。要在設(shè)計(jì)類時(shí)給予足夠的關(guān)注,，才能實(shí)現(xiàn)這一目標(biāo)。

第7章 高質(zhì)量的子程序

High-Quality Routines

Key Points

創(chuàng)建子程序最主要的目的是提高程序的可管理性,，當(dāng)然也有其他一些好的理由,。其中，節(jié)省代碼空間只是一個(gè)次要理由,；提高可讀性,、可靠性和可修改性等原因都更重要一些。

有時(shí)候,，把一些簡單的操作寫成獨(dú)立的子程序也非常有價(jià)值,。

子程序可以按照其內(nèi)聚性分為很多類，而你應(yīng)該讓大多數(shù)子程序具有功能上的內(nèi)聚性,，這是最佳的一種內(nèi)聚性,。

子程序的名字是它的質(zhì)量的指示器。如果名字糟糕但恰如其分,，那就說明這個(gè)子程序設(shè)計(jì)得很差勁,。如果名字糟糕而且又不準(zhǔn)確，那么它就反映不出程序是干什么的,。不管怎樣,，糟糕的名字都意味著程序需要修改。

只有在某個(gè)子程序的主要目的是返回由其名字所描述的特定結(jié)果時(shí),，才應(yīng)該使用函數(shù),。

細(xì)心的程序員會(huì)非常謹(jǐn)慎地使用宏，而且只在萬不得已時(shí)才使用,。

第8章 防御式編程

Defensive Programming

Key Points

最終產(chǎn)品代碼中對(duì)錯(cuò)誤的處理方式要比“垃圾進(jìn),，垃圾出”復(fù)雜得多。

防御式編程技術(shù)可以讓錯(cuò)誤更容易發(fā)現(xiàn),、更容易修改,，并減少錯(cuò)誤對(duì)產(chǎn)品代碼的破壞。

斷言可以幫助人盡早發(fā)現(xiàn)錯(cuò)誤,，尤其是在大型系統(tǒng)和高可靠性的系統(tǒng)中,，以及快速變化的代碼中,。

關(guān)于如何處理錯(cuò)誤輸入的決策是一項(xiàng)關(guān)鍵的錯(cuò)誤處理決策，也是一項(xiàng)關(guān)鍵的高層設(shè)計(jì)決策,。

異常提供了一種與代碼正常流程角度不同的錯(cuò)誤處理手段。如果留心使用異常,，它可以成為程序員知識(shí)工具箱中的一項(xiàng)有益補(bǔ)充,，同時(shí)也應(yīng)該在異常和其他錯(cuò)誤處理手段之間進(jìn)行權(quán)衡比較。

針對(duì)產(chǎn)品代碼的限制并不適用于開發(fā)中的軟件,。你可以利用這一優(yōu)勢(shì)在開發(fā)中添加有助于更快地排查錯(cuò)誤的代碼,。

第9章 偽代碼編程過程

The Pseudocode Programming Process

Key Points

創(chuàng)建類和子程序通常都是一個(gè)迭代的過程。在創(chuàng)建子程序的過程中獲得的認(rèn)識(shí)常常會(huì)反過來影響類的設(shè)計(jì),。

編寫好的偽代碼需要使用易懂的英語,，要避免使用特定編程語言中才有的特性，同時(shí)要在意圖的層面上寫偽代碼（即描述該做什么,，而不是要怎么去做）,。

偽代碼編程過程是一個(gè)行之有效的做詳細(xì)設(shè)計(jì)的工具，它同時(shí)讓編碼工作更容易,。偽代碼會(huì)直接轉(zhuǎn)化成注釋,，從而確保了注釋的準(zhǔn)確度和實(shí)用性。

不要只停留在你所想到的第一個(gè)設(shè)計(jì)方案上,。反復(fù)使用偽代碼做出多種方案,，然后選出其中最佳的一種方案再開始編碼。

每一步完成后都要檢查你的工作成果,，還要鼓勵(lì)其他人幫你來檢查,。這樣你就會(huì)在投入精力最少的時(shí)候，用最低的成本發(fā)現(xiàn)錯(cuò)誤,。

第三部分：變量

Variables

第10章 使用變量的一般事項(xiàng)

General Issues in Using Variables

Key Points

數(shù)據(jù)初始化過程很容易出錯(cuò),，所以請(qǐng)用本章描述的初始化方法來避免由于非預(yù)期的初始值而造成的錯(cuò)誤。

最小化每個(gè)變量的作用域,。把同一變量的引用點(diǎn)集中在一起,。把變量限定在子程序或類的范圍之內(nèi)。避免使用全局?jǐn)?shù)據(jù),。

把使用相同變量的語句盡可能集中在一起,。

早期綁定會(huì)減低靈活性，但有助于減小復(fù)雜度,。晚期綁定可以增加靈活性,，同時(shí)增加復(fù)雜度。

把每個(gè)變量用于唯一的用途,。

第11章 變量名的力量

The Power of Variable Names

Key Points

好的變量名是提高程序可讀性的一項(xiàng)關(guān)鍵要素,。對(duì)特殊種類的變量,，比如循環(huán)下標(biāo)和狀態(tài)變量，需要加以特殊的考慮,。

名字要盡可能地具體,。那些太模糊或者太通用以致于能夠用于多種目的的名字通常都是很不好的。

命名規(guī)則應(yīng)該能夠區(qū)分局部數(shù)據(jù),、類數(shù)據(jù)和全局?jǐn)?shù)據(jù),。它們還應(yīng)當(dāng)可以區(qū)分類型名、具名常量,、枚舉類型名字和變量名,。

無論做哪種類型項(xiàng)目，你都應(yīng)該采用某種變量命名規(guī)則,。你所采用的規(guī)則的種類取決于你的程序的規(guī)模,，以及項(xiàng)目成員的人數(shù)。

現(xiàn)代編程語言很少需要用到縮寫,。如果你真的要使用縮寫,，請(qǐng)使用項(xiàng)目縮寫詞典或者標(biāo)準(zhǔn)前綴來幫助理解縮寫。

代碼閱讀的次數(shù)遠(yuǎn)遠(yuǎn)多于編寫的次數(shù),。確保你所取的名字更側(cè)重于閱讀方便而不是編寫方便,。

第12章 基本數(shù)據(jù)類型

Fundamental Data Types

Key Points

使用特定的數(shù)據(jù)類型就意味著要記住適用于各個(gè)類型的很多獨(dú)立的原則。用本章的核對(duì)表來確認(rèn)你已經(jīng)對(duì)常見問題做了考慮,。

如果你的語言支持,，創(chuàng)建自定義類型會(huì)使得你的程序更容易修改，并更具有自描述性,。

當(dāng)你用typedef或者其等價(jià)方式創(chuàng)建了一個(gè)簡單類型的時(shí)候,，考慮是否更應(yīng)該創(chuàng)建一個(gè)新的類。

第13章 不常見的數(shù)據(jù)類型

Unusual Data Types

Key Points

結(jié)構(gòu)體可以使得程序更簡單,、更容易理解,，以及更容易維護(hù)。

每當(dāng)你打算使用結(jié)構(gòu)體的時(shí)候,，考慮采用類是不是會(huì)工作得更好,。

指針很容易出錯(cuò)。用訪問器子程序或類以及防御式編程實(shí)踐來保護(hù)自己的代碼,。

避免用全局變量,，不只是因?yàn)樗鼈兒芪ｋU(xiǎn)，還是因?yàn)槟憧梢杂闷渌玫姆椒▉砣〈鼈儭?/p>

如果你不得不使用全局變量,，那么就通過訪問器子程序來使用它,。訪問器子程序能為你帶來全局變量所能帶來的一切優(yōu)點(diǎn)，還有一些額外好處,。

第四部分：語句

Statements

第14章 組織直線型代碼

Organizing Straight-Line Code

Key Points

組織直線型代碼的最主要原則是按照依賴關(guān)系進(jìn)行排列,。

可以用好的子程序名,、參數(shù)列表、注釋,，以及--如果代碼足夠重要--內(nèi)務(wù)管理變量來讓依賴關(guān)系變得更明顯,。

如果代碼之間沒有順序依賴關(guān)系，那就設(shè)法使相關(guān)的語句盡可能地接近,。

第15章 使用條件語句

Using Conditionals

Key Points

對(duì)于簡單的if-else語句,，請(qǐng)注意if子句和else子句的順序，特別是用它來處理大量錯(cuò)誤的時(shí)候,。要確認(rèn)正常的情況是清晰的。

對(duì)于if-then-else語句串和case語句,，選擇一種最有利于閱讀的排序,。

為了捕捉錯(cuò)誤，可以使用case語句中的default子句（默認(rèn)子句）,，或者使用if-then-else語句串中的最后那個(gè)else子句,。

各種控制結(jié)構(gòu)并不是生來平等的。請(qǐng)為代碼的每個(gè)部分選用最合適的控制結(jié)構(gòu),。

第16章 控制循環(huán)

Controlling Loops

Key Points

循環(huán)很復(fù)雜,。保持循環(huán)簡單將有助于別人閱讀你的代碼。

保持循環(huán)簡單的技巧包括：避免使用怪異的循環(huán),、減少嵌套層次,、讓入口和出口一目了然、把內(nèi)務(wù)操作代碼放在一起,。

循環(huán)下標(biāo)很容易被濫用,。因此命名要準(zhǔn)確，并且要把他們各自僅用于一個(gè)用途,。

仔細(xì)地考慮循環(huán),，確認(rèn)它在每一種情況下都運(yùn)行正常，并且在所有可能的條件下都能退出,。

第17章 不常見的控制結(jié)構(gòu)

Unusual Control Structures

Key Points

多個(gè)return可以增強(qiáng)子程序的可讀性和可維護(hù)性,，同時(shí)可以避免產(chǎn)生很深的嵌套邏輯。但是使用它的時(shí)候要多加小心,。

遞歸能夠很優(yōu)雅地解決一小部分問題,。對(duì)它的使用也要倍加小心。

在少數(shù)情況下,，goto是編寫可讀性和可維護(hù)代碼的最佳方法,。但這種情況非常罕見。除非萬不得已,，不要使用goto,。

第18章 表驅(qū)動(dòng)法

Table-Driven Methods

Key Points

表提供了一種復(fù)雜的邏輯和繼承結(jié)構(gòu)的替換方案,。如果你發(fā)現(xiàn)自己對(duì)某個(gè)應(yīng)用程序的邏輯或者繼承樹關(guān)系感到困惑，那么問問自己它是否可以通過一個(gè)查詢表來加以簡化,。

使用表的一項(xiàng)關(guān)鍵決策是決定如何去訪問表,。你可以采取直接訪問、索引訪問或者階梯訪問,。

使用表的另一項(xiàng)關(guān)鍵決策是決定應(yīng)該把什么內(nèi)容放入表中,。

第19章 一般控制問題

General Control Issues

Key Points

使布爾表達(dá)式簡單可讀，將非常有助于提高你的代碼的質(zhì)量,。

深層次的嵌套使得子程序變得難以理解,。所幸的是，你可以相對(duì)容易地避免這么做,。

結(jié)構(gòu)化編程是一種簡單并且仍然適用的思想：你可以通過把順序,、選擇和循環(huán)三者組合起來而開發(fā)出任何程序。

將復(fù)雜度降低到最低水平是編寫高質(zhì)量代碼的關(guān)鍵,。

第五部分：代碼改善

Code Improvement

第20章 軟件質(zhì)量概述

The Software-Quality Landscape

Key Points

開發(fā)高質(zhì)量代碼最終并沒有要求你付出更多,，只是你需要對(duì)資源進(jìn)行重新分配，以低廉的成本來防止缺陷出現(xiàn),，從而避免代價(jià)高昂的修正工作,。

并非所有的質(zhì)量保證目標(biāo)都可以全部實(shí)現(xiàn)。明確哪些目標(biāo)是你希望達(dá)到的,，并就這些目標(biāo)和團(tuán)隊(duì)成員進(jìn)行溝通,。

沒有任何一種錯(cuò)誤檢測(cè)方法能夠解決全部問題，測(cè)試本身并不是排除錯(cuò)誤的最有效方法,。成功的質(zhì)量保證計(jì)劃應(yīng)該使用多種不同的技術(shù)來檢查各種不同類型的錯(cuò)誤,。

在構(gòu)建期間應(yīng)當(dāng)使用一些有效的質(zhì)量保證技術(shù)，但在這之前,，一些具有同樣強(qiáng)大功能的質(zhì)量保證技術(shù)也是必不可少的,。錯(cuò)誤發(fā)現(xiàn)越早，它與其余代碼的糾纏就越少,，由此造成的損失也越小,。

軟件領(lǐng)域的質(zhì)量保證是面向過程的。軟件開發(fā)與制造業(yè)不一樣,，在這里并不存在會(huì)影響最終產(chǎn)品的重復(fù)的階段,，因此，最終產(chǎn)品的質(zhì)量受到開發(fā)軟件所用的過程的控制,。

第21章 協(xié)同構(gòu)建

Collaborative Construction

Key Points

協(xié)同開發(fā)實(shí)踐往往能比測(cè)試發(fā)現(xiàn)更多的缺陷,，并且更有效率。

協(xié)同開發(fā)實(shí)踐所發(fā)現(xiàn)錯(cuò)誤的類型通常跟測(cè)試所發(fā)現(xiàn)的不同，這意味著你需要同時(shí)使用詳查和測(cè)試來保證你軟件的質(zhì)量,。

正式檢查通過運(yùn)用核對(duì)表,、準(zhǔn)備工作、明確定義的角色以及對(duì)方法的持續(xù)改善,，將缺陷偵測(cè)的效率提升至最高,。它往往能比走查發(fā)現(xiàn)更多的缺陷。

通常,，結(jié)對(duì)編程擁有和詳查相同的成本,，并能產(chǎn)生質(zhì)量相當(dāng)?shù)拇a。當(dāng)需要縮短開發(fā)周期的時(shí)候,，結(jié)對(duì)編程就非常有價(jià)值,。相對(duì)于單獨(dú)工作來說，有些開發(fā)人員更喜歡結(jié)對(duì)工作,。

正式檢查可以應(yīng)用在除代碼之外的很多工作成果上,，例如需求、設(shè)計(jì)以及測(cè)試用例等,。

走查和代碼閱讀是詳查的替代方案。代碼閱讀更富有彈性,，能有效地利用每個(gè)人的時(shí)間,。

第22章 開發(fā)者測(cè)試

Developer Testing

Key Points

開發(fā)人員測(cè)試是完整測(cè)試策略的一個(gè)關(guān)鍵部分。獨(dú)立測(cè)試也很重要,，但這一主題超出了本書的范圍,。

同編碼之后編寫測(cè)試用例相比較，編碼開始之前編寫測(cè)試用例,，工作量和花費(fèi)的實(shí)際差不多,，但是后者可以縮短缺陷-偵測(cè)-調(diào)試-修正這一周期。

即使考慮到了各種可用的測(cè)試手段,，測(cè)試仍然只是良好軟件質(zhì)量計(jì)劃的一部分,。高質(zhì)量的開發(fā)方法至少和測(cè)試一樣重要，這包括盡可能減少需求和設(shè)計(jì)階段的缺陷,。在檢測(cè)錯(cuò)誤方面,，協(xié)同開發(fā)的成效至少與測(cè)試相當(dāng)。這些方法所檢測(cè)錯(cuò)誤的類型也各不相同,。

你可以根據(jù)各種不同的思路來產(chǎn)生很多測(cè)試用例,，這些思路包括基礎(chǔ)測(cè)試、數(shù)據(jù)流分析,、邊界分析,、錯(cuò)誤數(shù)據(jù)類型以及正確數(shù)據(jù)類型等。你還可以通過猜測(cè)錯(cuò)誤的方式得到更多的測(cè)試用例,。

錯(cuò)誤往往集中在少數(shù)幾個(gè)容易出錯(cuò)的類和子程序上,。找出這部分代碼,，重新設(shè)計(jì)和編寫它們。

測(cè)試數(shù)據(jù)本身出錯(cuò)的密度往往比被測(cè)代碼還要高,。查找這種錯(cuò)誤完全是浪費(fèi)時(shí)間,，又不能對(duì)代碼有所改善，因此測(cè)試數(shù)據(jù)里面的錯(cuò)誤更加讓人煩惱,。要像寫代碼一樣小心地開發(fā)測(cè)試用例,，這樣才能避免產(chǎn)生這種問題。

自動(dòng)化測(cè)試總體來說是很有用的,，也是進(jìn)行回歸測(cè)試的基礎(chǔ),。

從長遠(yuǎn)來看，改善測(cè)試過程的最好辦法就是將其規(guī)范化,，并對(duì)其進(jìn)行評(píng)估,，然后用從評(píng)估中獲得的經(jīng)驗(yàn)教訓(xùn)來改善這個(gè)過程。

第23章 調(diào)試

Debugging

Key Points

調(diào)試同整個(gè)軟件開發(fā)的成敗息息相關(guān),。最好的解決之道是使用本書中介紹的其他方法來避免缺陷的產(chǎn)生,。然而，花點(diǎn)時(shí)間來提高自己的調(diào)試技能還是很劃算的,，因?yàn)閮?yōu)秀和拙劣的調(diào)試表現(xiàn)之間的差距至少是10:1,。

要想成功，系統(tǒng)化地查找和改正錯(cuò)誤的方法至關(guān)重要,。要專注于你的調(diào)試工作,，讓每一次測(cè)試都能讓你朝著正確的方向前進(jìn)一步。要使用科學(xué)的調(diào)試方法,。

在動(dòng)手解決問題之前,，要理解問題的根本。胡亂猜測(cè)錯(cuò)誤的來源和隨機(jī)修改將會(huì)讓你的程序陷入比剛開始調(diào)試時(shí)更為糟糕的境地,。

將編譯器警告級(jí)別設(shè)置為最嚴(yán)格,，把警告信息所報(bào)告的錯(cuò)誤都改正。如果你忽略了明顯的錯(cuò)誤,，那么要改正那些微妙的錯(cuò)誤就會(huì)非常麻煩,。

調(diào)試工具對(duì)軟件開發(fā)而言是強(qiáng)有力的支持手段。找出這些工具并加以應(yīng)用,，當(dāng)然,，請(qǐng)記得在調(diào)試的時(shí)候開動(dòng)腦筋。

第24章 重構(gòu)

refactoring

Key Points

修改是程序一生都要面對(duì)的事情,，不僅包括最初的開發(fā)階段,，還包括首次發(fā)布之后。

在修改中軟件的質(zhì)量要么改進(jìn)，要么惡化,。軟件演化的首要法則就是代碼演化應(yīng)當(dāng)提升程序的內(nèi)在質(zhì)量,。

重構(gòu)成功之關(guān)鍵在于程序員應(yīng)學(xué)會(huì)關(guān)注那些標(biāo)志著代碼需要重構(gòu)的眾多的警告或“代碼臭味”。

重構(gòu)成功的另一要素是程序員應(yīng)當(dāng)掌握大量特定的重構(gòu)方法,。

重構(gòu)成功的最后要點(diǎn)在于要有安全重構(gòu)的策略,。一些重構(gòu)方法會(huì)比其他重構(gòu)方法要好。

開發(fā)階段的重構(gòu)是提升程序質(zhì)量的最佳時(shí)機(jī),，因?yàn)槟憧梢粤⒖套寗倓偖a(chǎn)生的改變夢(mèng)想變成現(xiàn)實(shí),。請(qǐng)珍惜這些開發(fā)階段的天賜良機(jī)！

第25章 代碼調(diào)整策略

Code-Tuning Strategies

Key Points

性能只是軟件整體質(zhì)量的一個(gè)方面,，通常不是最重要的,。精細(xì)的代碼調(diào)整也只是實(shí)現(xiàn)整體性能的一種方法，通常也不是決定性的,。相對(duì)于代碼本身的效率而言,，程序的架構(gòu)、細(xì)節(jié)設(shè)計(jì)以及數(shù)據(jù)結(jié)構(gòu)和算法選擇對(duì)程序的運(yùn)行速度和資源占用的影響通常會(huì)更大,。

定量測(cè)量是實(shí)現(xiàn)性能最優(yōu)化的關(guān)鍵,。定量測(cè)量需要找出能真正決定程序性能的部分，在修改之后,，應(yīng)當(dāng)通過重復(fù)測(cè)量來明確修改是提高還是降低了軟件的性能,。

絕大多數(shù)的程序都有那么一小部分代碼耗費(fèi)了絕大部分的運(yùn)行時(shí)間。如果沒有測(cè)量,，你不會(huì)知道是哪一部分代碼,。

代碼調(diào)整需要反復(fù)嘗試,，這樣才能獲得理想的性能提高,。

為性能優(yōu)化工作做好準(zhǔn)備的最佳方式就是在最初階段編寫清晰的代碼，從而使代碼在后續(xù)工作中易于理解和修改,。

第26章 代碼調(diào)整技術(shù)

Code-Tuning Techniques

Key Points

優(yōu)化結(jié)果在不同的語言,、編譯器和環(huán)境下有很大差異。如果沒有對(duì)每一次的優(yōu)化進(jìn)行測(cè)量,，你將無法判斷優(yōu)化到底是幫助還是損害了這個(gè)程序,。

第一次優(yōu)化通常不會(huì)是最好的。即使找到了效果很不錯(cuò)的,，也不要停下擴(kuò)大戰(zhàn)果的步伐,。

代碼調(diào)整這一話題有點(diǎn)類似于核能，富有爭議,，甚至?xí)屓藳_動(dòng),。一些人認(rèn)為代碼調(diào)整損害了代碼可讀性和可維護(hù)性，他們絕對(duì)會(huì)將其棄之不用。其他人則認(rèn)為只要有適當(dāng)?shù)陌踩Ｕ?，代碼調(diào)整對(duì)程序是有益的,。如果你決定使用本章所述的調(diào)整方法，請(qǐng)務(wù)必謹(jǐn)慎行事,。

第六部分：系統(tǒng)考慮

System Considerations

第27章 程序規(guī)模對(duì)構(gòu)建的影響

How Program Size Affects Construction

Key Points

隨著項(xiàng)目規(guī)模的擴(kuò)大,，交流需要加以支持。大多數(shù)方法論的關(guān)鍵點(diǎn)都在于減少交流中的問題,，而一項(xiàng)方法論的存亡關(guān)鍵也應(yīng)取決于它能否促進(jìn)交流,。

在其他條件都相等的時(shí)候，大項(xiàng)目的生產(chǎn)率會(huì)低于小項(xiàng)目,。

在其他條件都相等的時(shí)候,，大項(xiàng)目的每千行代碼錯(cuò)誤率會(huì)高于小項(xiàng)目。

在小項(xiàng)目里的一些看起來“理當(dāng)如此”的活動(dòng)在大項(xiàng)目中必須仔細(xì)地計(jì)劃,。隨著項(xiàng)目規(guī)模擴(kuò)大,，構(gòu)建活動(dòng)的主導(dǎo)地位逐漸降低。

放大輕量級(jí)的方法論要好于縮小重量級(jí)的方法論,。最有效的辦法是使用“適量級(jí)”方法論,。

第28章 管理構(gòu)建

Managing Construction

Key Points

好的編碼實(shí)踐可以通過“貫徹標(biāo)準(zhǔn)”或者“使用更為靈活的方法”來達(dá)到。

配置管理,，如果應(yīng)用得當(dāng),，會(huì)使程序員的工作變得更加輕松。特別包括變更控制,。

好的軟件評(píng)估是一項(xiàng)重大挑戰(zhàn),。成功的關(guān)鍵包括采用多種方法、隨著項(xiàng)目的開展而修繕評(píng)估結(jié)果,，以及很好地利用數(shù)據(jù)來創(chuàng)建評(píng)估等,。

度量是構(gòu)建管理成功的關(guān)鍵。你可以采取措施度量項(xiàng)目的任何方面,，而這要比根本不度量好得多,。準(zhǔn)確的度量是制定準(zhǔn)確的進(jìn)度表、質(zhì)量控制和改進(jìn)開發(fā)過程的關(guān)鍵,。

程序員和管理人員都是人,，在把他們當(dāng)人看的時(shí)候工作得最好。

第29章 集成

Integration

Key Points

構(gòu)建的先后次序和集成的步驟會(huì)影響設(shè)計(jì),、編碼,、測(cè)試各類的順序。

一個(gè)經(jīng)過充分思考的集成順序能減少測(cè)試的工作量,，并使調(diào)試變?nèi)菀住?/p>

增量集成有若干類型,，而且--除非項(xiàng)目是微不足道的--任何一種形式的增量集成都比階段式集成好,。

針對(duì)每個(gè)特定的項(xiàng)目，最佳的集成步驟通常是自頂向下,、自底向上,、風(fēng)險(xiǎn)導(dǎo)向及其他集成方法的某種組合。T-型集成和豎直分塊集成通常都能工作得很好,。

daily build 能減少集成的問題,，提升開發(fā)人員的士氣，并提供非常有用的項(xiàng)目管理信息,。

第30章 編程工具

Programming Tools

Key Points

程序員有時(shí)會(huì)在長達(dá)數(shù)年的時(shí)間里忽視某些最強(qiáng)大的工具,，之后才發(fā)現(xiàn)并使用之。

好的工具能讓你的日子過得安逸得多,。

下面這些工具已經(jīng)可用了：編輯,、分析代碼質(zhì)量、重構(gòu),、版本控制,、除錯(cuò)、測(cè)試,、代碼調(diào)整,。

你能打造許多自己用的專用工具。

好的工具能減少軟件開發(fā)中最單調(diào)乏味的工作的量,，但它不能消除對(duì)“編程”的需要,，雖然它會(huì)持續(xù)地重塑（reshape）“編程”的含義。

第七部分：軟件工藝

Software Craftsmanship

第31章 布局與風(fēng)格

Layout and Style

Key Points

可視化布局的首要任務(wù)是指明代碼的邏輯組織,。評(píng)估該任務(wù)是否實(shí)現(xiàn)的指標(biāo)包括準(zhǔn)確性,、一致性,、易讀性和可維護(hù)性,。

外表悅目比起其他指標(biāo)是最不重要的。然而,，如果其他指標(biāo)都達(dá)到了,，代碼又質(zhì)量好,，那么布局效果看上去也會(huì)不錯(cuò),。

Visual Basic具有純代碼塊風(fēng)格,，而Java的傳統(tǒng)做法就是使用純塊風(fēng)格，所以若用這些語言編程,，就請(qǐng)使用純代碼塊風(fēng)格,。C++中，模擬純代碼塊或者begin-end塊編輯都行之有效,。

結(jié)構(gòu)化代碼有其自身目的,。始終如一地沿用某個(gè)習(xí)慣而少來創(chuàng)新,。不能持久的布局規(guī)范只會(huì)損害可讀性。

布局的很多方面涉及信仰問題,。應(yīng)試著將客觀需要和主觀偏好區(qū)分開來,。定出明確的指標(biāo)，在此基礎(chǔ)上再討論風(fēng)格參數(shù)的選擇,。

第32章 自說明代碼

Self-Documenting Code

Key Points

該不該注釋是個(gè)需要認(rèn)真對(duì)待的問題,。差勁的注釋只會(huì)浪費(fèi)時(shí)間，幫倒忙,；好的注釋才有價(jià)值,。

源代碼應(yīng)當(dāng)含有程序大部分的關(guān)鍵信息。只要程序依然在用,，源代碼比其他資料都能保持更新,，故而將重要信息融入代碼是很有用處的。

好代碼本身就是最好的說明,。如果代碼太糟,，需要大量注釋，應(yīng)先試著改進(jìn)代碼,，直至無須過多注釋為止,。

注釋應(yīng)說出代碼無法說出的東西--例如概述或用意等信息。

有的注釋風(fēng)格需要許多重復(fù)性勞動(dòng),，應(yīng)舍棄之,，改用易于維護(hù)的注釋風(fēng)格。

第33章 個(gè)人性格

Personal Character

Key Points

人的個(gè)性對(duì)其編程能力有直接影響,。

最有關(guān)系的性格為：謙虛,、求知欲、誠實(shí),、創(chuàng)造性和紀(jì)律,，以及高明的偷懶。

程序員高手的性格與天分無關(guān),，而任何事都與個(gè)人發(fā)展相關(guān),。

出乎意料的是，小聰明,、經(jīng)驗(yàn),、堅(jiān)持和瘋狂既有助也有害。

很多程序員不愿主動(dòng)吸收新知識(shí)和技術(shù),，只依靠工作時(shí)偶爾接觸新的信息,。如果你能抽出少量時(shí)間閱讀和學(xué)習(xí)編程知識(shí)，要不了多久就能鶴立雞群,。

好性格與培養(yǎng)正確的習(xí)慣關(guān)系甚大,。要成為杰出的程序員,，先要養(yǎng)成良好習(xí)慣，其他自然水到渠成,。

第34章 軟件工藝的話題

Themes in Software Craftsmanship

Key Points

編程的主要目的之一是管理復(fù)雜性,。

編程過程對(duì)最終產(chǎn)品有深遠(yuǎn)影響。

合作開發(fā)要求團(tuán)隊(duì)成員之間進(jìn)行廣泛溝通,，甚于同計(jì)算機(jī)的交互,；而單人開發(fā)則是自我交流，其次才是與計(jì)算機(jī),。

編程規(guī)范一旦濫用,，只會(huì)雪上加霜；使用得當(dāng)則能為開發(fā)環(huán)境帶來良好機(jī)制,，有助于管理復(fù)雜性和相互溝通,。

編程應(yīng)基于問題域而非解決方案，這樣便于復(fù)雜性管理,。

注意警告信息,，將其作為編程的疑點(diǎn)，因?yàn)榫幊處缀跏羌兇獾闹橇顒?dòng),。

開發(fā)時(shí)迭代次數(shù)越多,，產(chǎn)品的質(zhì)量越好。

墨守成規(guī)的方法有悖于高質(zhì)量的軟件開發(fā),。請(qǐng)將編程工具箱中填滿各種編程工具,，不斷提高自己挑選合適工具的能力。

第35章 何處有更多信息

Where to Find More Information