第六章當你編碼時

靠巧合程式設計

傳統智慧認為，專案一旦進入編碼階段，工作主要就是機械的把設計轉換成可執行語句。我們認為，這種態度是許多程式醜陋、結構糟糕、不可維護的最大一個原因。編碼不是機械工作，要想讓程式長久無誤的執行，每一分鐘都需要做出決策，且需要對這些決策進行仔細的思考和判斷。

1、靠巧合程式設計即程式碼正好是可執行的，至於為什麼能夠正常執行，卻不清楚。這是我們應該極力避免的。

2、在打算重構某個看起來有問題的程式碼時，我們會面臨這樣的疑惑，是否有必要冒著把能工作的東西弄糟的風險呢？這時我們可以考慮一下幾個理由：

它也許不是真的能工作，只是看起來能工作。你依靠的邊界條件也許只是一個巧合。多餘和沒必要的呼叫會讓你的程式碼變慢並增加新 bug 的風險。

演算法效率

1、注重實效的程式設計師幾乎每天都要使用估算，估算的資源包括：時間、處理器、記憶體等等。

2、估算演算法即是我們熟知的時間複雜度，用O()表示，它有以下幾種常見型別。

O(1)，常量時間，不隨資料的多少變化
O(n)，線性時間，簡單的迴圈
O(m*n)，巢狀迴圈
O(log(n))，二分法，平衡二叉樹的查詢
O(nlog(n))，分而治之，快排
O(2^n)，指數級，斐波那契數列
3、不同的時間複雜度在達到一定數量級的時候將相差很多，所以某些情況我們要想方設法優化演算法的效率。我們主要需要關注的是是複雜度的階。在確認了演算法之後，還需要對其進行測試。

4、最好的並非總是最好的，是否使用最優演算法，還需要根據我們遇到的實際情況。有時資料量很小的情況，演算法的效率是可以忽略不計的。

重構

1、重寫、重做和重新架構程式碼合起來，稱為重構。

2、當代碼出現以下特徵，就應該考慮重構了：

出現重複內容，違反DRY原則。
非正交的設計。
知識過時了，或者你對某部分的瞭解更深一步。
對效能造成了影響。
3、重構的原則：早重構、常重構。重構面臨的敵人通常都是時間，但這個藉口並不成立，因為之後由此引發的時間額外消耗很可能更多。

易於測試的程式碼

1、軟體 IC 是人們在討論可複用性和基於元件的開發時喜歡使用的比喻。意思是積體電路晶片可以很容易的進行組合，我們希望軟體開發也能達到這個效果。晶片的設計有完善的測試，同樣的軟體開發也可以做同樣的事情。

2、針對合約進行測試及為測試而設計，即 TDD 測試驅動開發。

3、編寫單元測試，對比較大的專案，將每個測試都放進一個子目錄。

4、使用測試裝備。構建一套完善的測試體系，它能夠記錄測試狀態，分析輸出結果是否符合預期，以及選擇和執行測試。

5、推進測試文化，儘可能完善地測試你的軟體，否則你的使用者就得替你測試。

邪惡的嚮導

1、為什麼稱嚮導（wizard）是邪惡的呢，這是因為通過工具生成的程式碼，很容易被我們忽略，在這種情況下你編寫的過程更傾向於靠巧合程式設計。

2、這裡不是抵制嚮導程式碼，而是在強調，不要使用你不理解的嚮導程式碼。如果使用，一定要清楚它的機制。

3、開發每天都在使用不完全理解的事物，比如用於排程的演算法、各種系統庫的工作機制等。需要注意的是，這些屬於底層依賴，他們也是嚮導，但不是應用本身的一部分，我們可以對這部分有所瞭解，但他們不屬於邪惡的嚮導。