> 任何傻瓜都可以寫出電腦能懂的代碼，但好的程式員可以寫出人類能懂的代碼—–Martin Fowler 如果你是新手，你可能會問，為什麼代碼需要設計原則？ 我想說的是肯定不是為了故作高深，存在即是合理。 如果寫了一個簡單的程式，你可能不需要設計原則。 如果你寫了一個複雜的，但是之後再也不會改，那麼 ...
任何傻瓜都可以寫出電腦能懂的代碼，但好的程式員可以寫出人類能懂的代碼—–Martin Fowler
如果你是新手，你可能會問，為什麼代碼需要設計原則？
我想說的是肯定不是為了故作高深，存在即是合理。
如果寫了一個簡單的程式，你可能不需要設計原則。
如果你寫了一個複雜的，但是之後再也不會改，那麼你也不需要。
但是現實生活中，基本上的軟體系統有一定複雜度，而且都在不斷的修改。所以我們需要寫出一個不僅讓機器看懂，還能夠讓人類看懂的代碼。
讓人類能看懂的代碼即是可維護性代碼，它包含兩個核心原則：高內聚、低耦合。
一個有助於實現高內聚低耦合的原則是關註點分離Separation of Concerns（SOC），關註點是軟體功能的不同部分，像業務邏輯或者表現方式，SOC是關於把系統分解成不同的可能沒有重疊的特性，比如儘量將業務邏輯放在領域層，而不是一部分放在存儲過程，一部分放在UI。
後來這些原則得到進一步的完善和強化，大師Robert C. Martin給出了5個更有效，更具體和可實施的原則，即比較流行的SOLID原則。
單一職責（SRP）：類應該儘可能簡單，專註於一個核心任務，
開閉原則（OCP）：即對擴展開放，對修改關閉
里氏替換原則（LSP）：子類可以替換他們的基類
介面分離原則（ISP）：介面隔離原則解決的是介面臃腫的問題，建議保持介面最低限度的函數
依賴反轉原則（DIP）：即高級模塊不應該依賴於低層模塊，二者都應該依賴於抽象，什麼意思呢？比如說你在開發asp.net MVC, Controller里需要訪問某個服務或者資料庫層，最好不要直接在controller里直接引用相關的實現類，而應該引用相關的服務和持久層的抽象，一般是相應的介面，通用的做法是使用IOC組件來做這個事情，如Unity，Autofac等。
除此以外，還有一些比較實用的原則：
1. DRY（Don’t Repeat Yourself）
2. 說，別問（Tell，Don’t Ask）
總的來說，這是對象建模的啟蒙原則，就OOP而言，創建軟體實體可以包含數據並暴露某些行為，
意思是你在實現某個功能的時候，避免請求數據併在某個外圍邏輯容器里處理，
舉個例子，比如一個訂單聚合根，計算訂單的價格只需要通過聚合根內的一個方法獲取就好了，不需要你在訂單聚合根意外的別的其他地方獲取訂單項再重新計算一遍了。
3. KISS（keep It Simple,Stupid）
法國詩人曾說，完美不是沒有東西可以增加，而是沒有東西可以減少，在軟體開發里，是為了防止過渡設計的情況發生。
4. YAGNI(You Ain’t Gonna Need It)
這個原則認為實現需求上沒有提到的任何功能都是有問題的，即在你認為自己可能需要而不是實際需要時實現一個函數可能會給你帶來一些潛在的問題。
說了這麼多如何寫出好的代碼？寫出好的代碼，不是每個人天生就會的，他需要一個過程，一個重構的過程。
實際工作上，重構是每天都會發生的，你重構代碼不是因為他不工作了，而是為了更好的實現某些非功能性需求；如可讀性，可維護性，可測試性或可擴展性，或者為了提高性能。
常見的重構操作：
-
提取方法
-
提取介面
-
封裝欄位
-
重命名
-
使用新的組件代替舊的組件
點關註，不迷路。
如果您喜歡這篇文章，請不要忘記點贊、關註、轉發，謝謝！如果您有任何高見，歡迎在評論區留言討論……
