當你編碼時
31, 靠巧合程式設計
怎樣靠巧合程式設計：
一開始就不知道它為什麼能工作。
實現的偶然：
因為**現在的編寫方式才得以發生的事情。最後會依靠沒有記入文件的錯誤或是邊界條件。
理由：它也許不是真的能工作--它也許只是看起來能工作。
你依靠的邊界條件也許只是乙個偶然。
沒有記入文件的行為可能會隨著庫的下一次發布而變化。
多餘的和不必要的呼叫會使你的**變慢。
多餘的呼叫還會增加引入它們自己的新bug的風險。
結論？
對於你編寫給別人呼叫的**，良好的模組化以及把實現隱藏再撰寫了良好文件的小介面之後，這樣一些基本原則都能對你有幫助。
對於你呼叫的例程，要只依靠記入了文件的行為。如果出於任何原因你無法做到這一點，那就充分地把你的各種假定記入文件。
語境的偶然：
只是你現在為gui環境編寫**，該模組就必須依靠給你的gui嗎？你是否依靠說英語的使用者？有文化的使用者？你還依靠別的什麼沒***的東西？
隱含的假定：
巧合可以在所有層面讓人誤入歧途--從生產需求知道測試。特別是測試，充滿了虛假的因果關係和巧合的輸出。不要假定，要證明。
don't program by coincidence
怎麼深思熟慮地程式設計
總是意識到你在做什麼。
不要盲目地程式設計。
按照計畫行事
依靠可靠的事物，不要依靠巧合或假定。
為你的假定建立文件。
不要只是測試你的**，還要測試你的假定。斷言
為你的工作劃分優先順序。把時間花在重要的方面，很可能也是最難的地方。如果基礎設施不正確，再好的口哨都沒用。
不要做歷史的奴隸。準備好進行重構。
所以下次有什麼東西看起來能工作，而你卻不知道為什麼，要確認它不是巧合。
32, 演算法速率
我們說估算演算法是什麼意思？
只要我們編寫的是含有迴圈或遞迴呼叫的程式，我們就會下意識地檢查執行時間和記憶體需求。
o()表示法：
1：常量型，訪問陣列元素，簡單語句
lg(n): 對數型，二分查詢
n：線性型，順序查詢
nlg(n)：比線性差，但不會差很多（快速排序，堆排序）
n的平方，平方律型（選擇和插入排序）
n的立方，立方型，2n×n 矩陣相乘。
cn，指數型，旅行商問題，集合劃分。
常識估算：
簡單迴圈，從1迴圈到n，很可能是o(n)
巢狀迴圈，o(m*n) -> o(n的平方）
二分法，o(ln(n))
分而治之，o(nln(n))
組合，常常用啟發式方法來優化。
實踐中的演算法速率：
時間和空間的權衡。
估算你的演算法的階，只需要幾個點就可以確定。
測試你的估算。
最好的並非總是最好的：
最快的演算法未必是最合適的。有時候追求簡單，快速。
33,重構
重寫，重做和重新架構**合併起來，成為重構，refactor
你應在何時進行重構：
不要對改動猶豫不決
重複，非正交的設計，過時的知識，效能。
現實世界的複雜情況：
重構就像是切除腫瘤，需要停止花時間修復。否則。。。
早重構，常重構。
如果不能立刻重構，將其加入計畫。
怎樣進行重構：
重構就是重新設計，新的事實、新的理解、新的需求等。
重構要慎重、深思熟慮、小心進行的活動。
1, 不要試圖在重構的同時增加新的功能。
2, 在開始重構之前，確保你擁有良好的測試。盡可能經常執行這些測試。這樣，如果你改壞了，你也會知道。
3, 採取短小、深思熟慮的步驟。在每個步驟後測試。
修改了**，也要修改依賴**的地方。最好一勞永逸地修正它，不要容忍破窗戶。
34, 易於測試的**
單元測試：
軟體的單元測試是對模組進行演練的**，建立某種人工環境，然後呼叫被測試的模組中的例程。然後不同的測試值，對返回值進行檢查。
針對合約進行測試：
**是否符合合約，以及合約的含義是否與我們所認為的一樣。邊界，前後條件等。
這種風格的測試要求你首先測試模組的自元件。這樣容易得知**出了錯誤。
為測試而設計。
早發現問題比解決問題更好。
編寫單元測試：
將它們放在方便的地方。
這個給開發者帶來無價的資源：
1, 一些例子，說明怎樣使用你的模組的所有功能。
2, 用於構建回歸測試、以驗證未來對**的任何改動是否正確的一種手段。
可以用#ifdef在編譯的時候跳過單元測試的**。
也可以借助shell指令碼。
使用測試裝置：
可以是gui驅動，也可以是makefile與perl指令碼組合
測試裝備都應該有以下功能：
用以指定設定與清理的標準途徑。
用以選擇個別或所有可用測試的方法。
分析輸出是否是預期結果的手段。
標準化的故障報告形式。
可以通過子元件來構成乙個系統，達到任意深度。
即興測試，臨時測試，print，或者互動。可能需要將它正式化。
構建測試視窗：
含有跟蹤訊息的日誌檔案就是一種機制，格式要正規一致。
使用不為普通使用者所知的熱鍵，來開啟診斷除錯視窗。
更大的程式，可以使用web伺服器。
測試文化：
測試是技術，更是文化。
測試你的軟體，否則你的使用者就得測試。
35，**的嚮導
謹慎使用wizard，嚮導為你寫好的**你可能不清楚。如果你不清楚，可能就是在靠巧合程式設計。
不要使用你不理解的嚮導**。
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...