# Clean Code - Ch12 羽化
這章主要是說，有四個簡單的守則，可以幫助你設計出簡單好用的代碼。
我自己的感覺這章是在說一個良好系統的準則，或者是要將你的代碼昇華到另一個層次，最基本的原則。

## 簡單設計四守則
四守則可以劃分為測試的部份以及重構的部分，先有良好的測試作為代碼的最後防線，你才可以安心地進行重構

**測試**

1. 執行完所有的測試

**重構**

2. 沒有重複的部分
3. 表達程式設計師的本意
4. 最小類別和方法的數量

## 1. 執行完所有的測試
系統必須要通過所有的測試來證明這個系統是可以被依賴的，不能被測試的系統，代表無法被驗證，而不能被驗證的系統，永遠不該被部屬

而為了確保系統是完全可測試的，我們就會傾向寫出小型、單一用途的類別，讓類別遵守單一職責原則(SRP)。而當你的類別是遵守SRP的，這樣對於寫測試就是一件簡單的事。而寫出越多的測試代碼，我們就會持續設計更多更容易被測試的代碼，我們就會持續寫出好的代碼。

為了讓測試更加容易，我們也會試圖減少緊密耦合的程式碼，使用像是相依性反向(DIP)原則、依賴注入、介面之類的工具，來幫助我們降低代碼的耦合度。

透過如此測試導向設計出來的系統，會讓我們持續寫出低耦合度與高擬聚度的設計，而有了測試代碼就能讓我們更能放心去重構。

## 2. 沒有重複的部分
重複的代碼是 **"良好設計的系統"** 的敵人，如果同一件事會一直重複做，應該要盡可能用現有的並且實作好的功能而不是重複做一樣的事。

我們應該要減少重複的代碼，重複的代碼會造成維護上的負擔，因為你必須要時時注意是否有在哪邊漏掉同步成最新的代碼，這樣就是潛在的風險。

所以我們應該盡量讓每個function都是不同的功能，並確保他們是獨特的且必要獨立出來的function。能重複使用就盡量重複使用，不要多開一個新的坑給後人。

**Bad：**

public class StringList 
{
    private List<string> list { get; set; }

    public int Size() {
        return list.Count();
    }
    
    public bool IsEmpty() {
        return 0 == list.Count();    
    }
}

**Good：**

public class StringList 
{
    private List<string> list { get; set; }

    public int Size() {
        return list.Count();
    }
    
    public bool IsEmpty() {
        return 0 == size();    
    }
}

## 3. 表達程式設計師的本意
再次強調命名的重要，變數、function或類別的命名可以讓代碼更容易閱讀。

當系統經過長久的開發而變得越來越龐大時，良好的命名可以降低後續接手的開發者所需要面對的成本(如看懂的時間成本)及風險(誤解原本的含意)。

**1. 選擇一個良好的名稱**
我們應該要在看完名稱後並對照其內容時不會感到有任何的意外。

**2. 讓function或類別簡短**
簡短的名稱可以加強表達力，小型的類別或function通常比較容易正確的命名而不會有一個太過空泛的名稱

**3. 可用設計模式做為類別名稱增加可讀性**
例如，設計模式(Design Pattern)通常與溝通與表達有關。用這些相關的命名可以簡潔地向其他開發者描述你的設計。
ex. CarFactory，可能是一個透過 Factory Pattern 來實作 Car 的類別

**4. 良好的單元測試具有良好的表達力**
可用單元測試來告訴開發者某類別的是用來做什麼的，以一種範例的方式來告訴開發者代碼的內容

## 4. 最小類別和方法的數量
前面三點一直在期望我們在開發時可以盡量將功能拆小來實現前面三點的概念，但這樣如果做過頭的話，反而會本末倒置而造成過度設計的問題，使得類別變得太多。

我們希望我們的function或類別保持簡短，但我們也應該要盡量讓系統保持簡短。

但我們也不能因為怕類別變得太多而在一些應該拆小的功能上停手，該拆的東西還是要拆，這點比較像是一種提醒的功能，重要性還是前面三點的重要性比較高。

###### tags: `Clean Code` `Book`