閱讀《程式碼大全2》，記錄了一些經典標語，直抵內心，頗有感觸。望與大家共勉，有些路走過了，才知道路不好走，但希望後來者能夠避免，不重蹈覆轍。這些努力就是沒有白費，希望您能夠列印一份，放在案頭，百無聊賴之時或遇到困難，望能一讀，給您一些小的啟發，想必也沒有浪費您的時間一讀。

1 除錯程式碼的難度是首次編寫這些程式碼的兩倍。 2 消除軟體缺陷實際上是最昂貴且最耗時的一種軟體工作。 3 測試永遠不可能徹底證明程式中沒有錯誤。 4 首先為人寫程式，其次才是為機器。 5 這段程式碼暗藏玄機。（應該需要重寫或者重構） 6 試圖沒有錯誤是最大的錯誤。 7 閱讀程式碼每小時能夠檢測出的缺陷要比測試高出80%左右。 8 一步到位的方法明顯比兩步走的方法更划算。 9 犯罪不是罪過，從中什麼都學不到才是罪過。（犯罪其實已經是罪過了）。 10 我的程式碼不好，所以我得讓它們不好懂。 11 不是高手時不假裝是高手。（知之為知之不知為不知，是知也）。 12 世界上沒有免費的午餐，即使有，味道也一定不會好到哪裡去。 13 如果你工作10年，你會得到10年經驗還是1年經驗的10次重複。 14 如果在尋找缺陷的時候遇到了麻煩，很可能是因為你的程式碼寫的不好。 15 匆忙動手解決問題是你所能做的最低效的事情之一。 16 不要受到所謂捷徑的誘惑。 17 好的佈局凸顯程式的邏輯結構。 18 不要重複自己，複製貼上即設計之謬。 19 不要為拙劣的程式碼編寫文件—應當重寫程式碼。 20 他們往往喜歡進行瑣碎和無理性的修改，而且他們通常不願意推翻以前不正確的修改。 21 理解程式本身，而不僅僅是問題。 22 你會看到你所希望看到的。 23 程式設計師們對於很小的修改常常不以為然。 24 大規模的重構孕育著災難。 25 開發階段的重構是提升程式質量的最佳時機，因為你可以立刻讓剛剛產生的改變夢想變成現實。請珍惜這些開發階段的天賜良機。 26 把一個結構化程式的腳塞進一隻面向物件的鞋子裡（怎麼描述得這麼準確）。 27 找不到錯誤的最常見的原因僅僅是因為忽視。 28 深入一門語言去程式設計，不浮於表面。 29 傻子都會為其失誤辯護，而多數傻瓜也確實這麼做。 30 你無法提升自己的聰明程度，但性格在一定程度上能夠改進。事實證明，個人性格對於造就出程式設計師高手更具有決定性意義。

1 "編碼 (coding)"它有一種把已經存在的設計機械地翻譯成計算機語言的意味。 2 重要的研發成果常常產自類比。 3 隱喻的作用更像啟示，而不是演算法。 4 品味一段“深奧的程式”就像面對的是一本出色的小說那樣。 5 如果你計劃拋棄一個，那麼你將會拋棄兩個。 6 增量式開發。 7 精心計劃，並非意味著事無鉅細的計劃或者過度的計劃。 8 瞄兩次，切一次（三思而後行）。 9 讓你的經驗來引導你吧。 10 軟體開發不僅僅是寫程式碼。 11 人生苦短，當有大量更好的選擇擺在你面前的時候，在一個荒蠻的軟體企業中工作是不明智的。 12 程式設計師是軟體食物鏈的最後一環，架構師吃掉需求，設計師吃掉架構，而程式設計師則消化設計。 13 在一開始把事情做好是最合算的，進行非必要的改動的代價是高昂的。 14 發現錯誤的時間要儘可能地接近引入該錯誤的時間。 15 充分詳盡地描述需求，是專案成功的關鍵，它甚至很可能比有效的構建技術更重要。 16 你思考的能力取決於你是否知道能夠表達該思想的詞彙。 17 “深入一種語言去程式設計”的程式設計師首先決定他要表達的思想是什麼，然後決定如何使用特定語言提供的工具類表達這些思想。 18 不要僅在“一種語言上程式設計”。

19 險惡的問題就是那種只有通過解決或部分解決才能被明確的問題。 20 沒有任何工具是用之四海皆靈的。 21 好的設計源於對一小批關鍵設計概念的理解。 22 本質的問題 偶然的問題 23 當沒人知道對一處程式碼的改動會對其他程式碼帶來什麼影響時，專案也就快停止進展了。 24 軟體的首要技術使命便是管理複雜度。 25 保持子程式的短小精悍。 26 從問題的領域著手，最抽象的層次上工作。 27 受著人類固有限制影響的程式設計師的底線，就是要寫出既讓自己容易理解，也能讓別人容易看懂，而且很少有錯誤的程式程式碼。 28 當我解決問題的時候，我從來不考慮美感，我只想著如何才能解決它。但一旦解決了問題，如果解決方法不夠優美的話，我就知道做錯了。 29 自明的系統 30 就近原則，即把相關的操作放在一起。 31 先別問系統做什麼，問問它想模仿什麼。 32 以複雜度的觀點看，抽象的主要好處就在於它使你能忽略無關的細節。 33 資訊隱藏：封裝和模組化。隱藏複雜度，隱藏變化源。 34 好的類介面就像是冰山的尖兒一樣，讓類的大部分內容都不會暴露出來。 35 我該隱藏些什麼？ 36 為了找到某樣事物，你需要查詢的地方越少，那麼改起它來就會越容易，越安全。 37 當你開發程式任一部分的程式碼時，都能安全地忽視程式中儘可能多的其餘部分。 38 深入挖掘能在問題領域工作，而非在底層實現領域工作的能量吧。 39 閱讀程式碼的次數要比編寫程式碼多得多。 40 如果在兩段子程式內編寫相似的程式碼，就意味著程式碼分解。 41 好的子程式名字能清晰地描述子程式所做的一切。 42 程式中有39%的錯誤都是屬於內部介面錯誤—也就是子程式間互相通訊時所發生的錯誤。 43 過程的名字中是否用了強烈清晰的“動詞+賓語”片語。 44 在防禦式駕駛中要建立這樣一種思維，那就是你永遠不能確定另一位司機將要做什麼。你要承擔起保護自己的責任，哪怕是其他司機犯的錯誤。 45 “進攻式程式設計”在開發階段讓它顯現出來，而在產品程式碼執行時讓它能夠自我恢復。 46 有時候，最好的防守正是大膽進攻。在開發時，慘痛的失敗，能讓你在釋出產品後不會敗得太慘。 47 虛擬碼程式設計過程的價值重大，卻很少有程式設計師真正挖掘出該過程的全部能量。 48 測試先行開發 契約式設計 49 一旦你真正開始編碼，你和你所寫下的程式碼就會有感情，從而就更難以拋棄不好的設計再重頭來過了。 50 不要只停留在你所想到的第一個設計方案上。 51 每一步完成後都要檢查你的工作成果，還要鼓勵其他人幫你來檢查，這樣你就會在投入精力最少的時候，用最低成本發現錯誤。

52 利用構建活動來填補需求和架構中存在的細小問題是一種行之有效的做法。但把藍圖設計精細到已經能完全展現出所有的細節則實在是一種低效做法。 53 就近原則，即把相關的操作放在一起。 54 把變數的引用點集中起來的主要好處是提高程式的可讀性。 55 開始時採用最嚴格的可見性，然後根據需要擴充套件變數的作用域。 56 方便性 智力可管理性 57 每個變數只用於單一用途。 58 一個好記的名字反映的通常都是問題，而不是解決方案。 59 一個好名字通常表達是what，而不是how. 60 如果你發現自己需要猜測某段程式碼的含義的時候，就該考慮為變數重新命名。 61 採用任何一項規則都要好於沒有規則。 62 規則的存在為你的程式碼增加了結構，減少了你需要考慮的事情。 63 去掉所有非前置母音（命名變數）。 64 記住，名字對於程式碼讀者的意義要比對作者更重要。 65 不是被動地看見了什麼，而是主動發現了什麼。 66 你想找到什麼，就能找到什麼。 67 資訊隱藏和模組化。 68 建立超過幾百行程式碼的程式的核心便是管理複雜度。

69 歷史包袱：早期設計所遺留下的問題如果沒有及時解決，隨著時間推移，這些後果會逐漸擴散，以致於我們要付出更大的代價來彌補才行。所以前期實際需要非常謹慎，對於拿不準的地方，寧願收緊也不能放鬆。畢竟，向ios那樣做加法（不斷新增新的功能和API）比Android這樣做減法（取消和收回之前公開的機制或者功能）要容易得多。 70 有多少次你花上了兩個小時來除錯原本只用三十分鐘就寫出來的程式碼。 71 /*"/**/ 終結註釋 72 理解程式本身，而不僅僅是問題。 73 匆忙動手解決問題是你所能做的最低效的事情。 74 修改程式碼時一定要有恰當的理由。 75 一次只做一個改動。 76 如果你想不出如何查詢類似缺陷，這就意味著你還沒有完全理解問題。 77 你會看到你所希望看到的。 78 軟體演化的基本準則就是演化應當提升程式的內在質量。 79 複製黏貼即設計之謬。 80 不要為拙劣的程式碼編寫文件—應當重寫程式碼。 81 應該把簡單的修改當做複雜修改加以對待。 82 不要把重構當做先寫後改的代名詞。 83 避免用重構來代替重寫。 84 開發階段的重構是提升程式質量的最佳時機。 85 不成熟優化的主要缺陷在於它缺乏前瞻性。 86 程式設計師在思考眼前這棵大樹到底有多高的時候，還能留意一下整個森林。 87 除非你對需要完成的工作一清二楚，否則絕不要對程式做優化。 88 只有4%的程式碼造成了50%甚至更多的效能瓶頸。 89 hot spot 90 除非對效果進行測量評估，否則你永遠無法確定某次優化帶來的影響。 91 你必須期望在你的程式碼裡有錯誤。儘管這種期望似乎有悖常理，但是你應該期望找到這個錯誤的人是你，而不是別人。 92 絕大多數錯誤往往與少數幾個具有嚴重缺陷的子程式有關。 93 缺乏應用領域知識，頻繁變動且相互矛盾的需求以及溝通和協調的失效。 94 錯誤理解設計。 95 自動化測試。 96 改善測試過程的最好辦法就是將其規範化，並對其進行評估，然後從評估中獲得的經驗教訓來改善這個過程。 97 明確你犯了哪種型別的錯誤。 98 從程式碼閱讀的角度分析程式碼質量。 99 審視自己解決問題的方法。審視自己修正缺陷的方法。 100 在公眾面前先指責別人犯了錯誤，最終卻發現錯誤其實由你而生。 101 把錯誤的發生穩定下來。 102 在一條死衚衕裡面走得太久。 103 拋開問題，休息一下。

104 如果你的坑挖得足夠深，你總會看到驚人的寶藏。 105 對每次的改進進行量化。 106 改善交流效率的常用方法是採用正式文件。 107 對於小專案（2000行程式碼或者更少）影響生產率的最大因素莫過於單個程式設計師的技巧。隨著專案規模和團隊規模的增大，組織方式對生產率的影響也隨之增大。 108 開發軟體產品的成本大約是開發軟體程式的3倍。 109 隨著專案規模的增長，構建活動將只佔專案工作的一小部分。 110 在社交場合，活動越正式，你所穿的服裝就會越不舒服。 111 安排一些好的程式碼示例供人蔘考。 112 強調程式碼是公有財產。 113 我必須能閱讀並理解這個專案的所有程式碼。 114 重要問題是你是想預測，還是想控制。 115 管理你的管理者意味著你需要告訴他應該這樣做而不是應該那樣做。你要表現得使你的管理者認為他仍然在管理你。 116 程式設計師和管理人員都是人，在把他們當人看的時候工作得最好。 117 開發人員花費多至50%的時間用於除錯，使定位錯誤變容易，就能將除錯的效率最大化，從而提高專案專案與生產率。 118 增量整合 119 專案及早開始整合。 120 底層的問題冒上來影響頂層系統的情況並不少見，

121 格式化的基本原理指出，好的佈局凸顯程式的邏輯結構。 122 傻子都會寫讓計算機理解的程式碼，而優秀程式設計師寫的是是人能看懂的程式碼。 123 好的佈局是可讀性的關鍵。 124 程式設計工作量的一小部分是寫讓機器讀的程式，大部分工作是寫能讓他人看懂的程式。 125 註釋應表達程式碼的意圖。程式碼本身應盡力做好說明。 126 註釋程式碼段時應注重“為何做why”，而不是”怎麼做how“。 127 不要註釋投機取巧的程式碼，應重寫之。 128 你無法提升自己的聰明程度，但性格在一定程度上能夠改進。個人性格對於造就出程式設計師高手更具有決定性意義。 129 人的智力是有限的，所以應和他人溝通來提高軟體質量。 130 對程式設計和開發過程做試驗，是學習程式設計的有效途徑之一。 131 犯錯不是罪過，從中學不到什麼才是罪過。 132 任何日後出色的程式設計師前幾年就做得很好。 133 不是高手時，不假裝是高手。 134 樂於承認錯誤。 135 透徹理解自己的程式，而不要只是編譯看看能否執行。 136 提供實際的狀況報告。 137 提供現實的進度方案，在上司面前堅持自己的意見。 138 力圖理解編譯器的警告，而非棄之不理。 139 真正優秀的程式設計師知道怎樣同別人融洽地工作和娛樂。 140 程式設計首先是人與人交流，其次才是與計算機交流。 141 我走出校園時，自以為是世上最好的程式設計師。 142 精緻的程式作品也要求許多約束。 143 一勞永逸的懶。 144 有效程式設計找那個最重要的工作是思考，而人思考時通常不會看上去很忙。 145 根據環境的不同，堅持可能是財富，也可能是負擔。 146 如果你工作10年，你會得到10年經驗還是1年經驗的10次重複。 147 深入一門語言去程式設計不浮於表面。 148 我想對嚴肅的程式設計師說的話就是：要花工作時間的一部分來檢討和提煉自己的方法。即使程式設計師總是奮力趕進度，或者滿足最後期限的要求，對方法的抽象是更明智的長遠投資。 149 專業的程式設計師總是寫可讀性好的程式碼。 150 警惕程式出現難以理解的跡象。 151 找不到錯誤的最常見原因僅僅是因為忽視。 152 應該在程式設計時使問題難以遁形。 153 “宗教信仰”在軟體開發中有著多種表現形式。非要堅持某種設計方法，篤信特定的佈局或註釋風格，極力避免全域性資料。不管哪種情況。都是不合適的。不要盲目跟風。而應使用一種混合的方法。可用激動人心最新方法做做試驗，但仍紮根於傳統的可靠的方法。 154 “試圖沒有錯誤”是最大的錯誤。 155 架構的本質是管理複雜性，抽象，分層，分治和演化思維是架構師政府複雜性的四種根本性武器。 156 備份，備份，備份，備份，備份，備份，備份，備份，備份，備份，備份，備份…