>[success] # 代碼分層 * **軟件分層架構是通過層來隔離不同的關注點**（變化相似的地方），以此來解決不同需求變化的問題，使得這種變化可以被控制在一個層里 * **代碼分層架構就是將軟件“元素”（代碼）按照“層”（代碼關系）的方式組織起來的一種結構** * 分層架構核心的原則是：**當請求或數據從外部傳遞過來后，必須是從上一層傳遞給下一層**  ***** 不采用分層，直接通信**會造成新的代碼耦合，增加代碼的復雜**，**分層的本質就是為了讓相似變化在各自的層內變化，而不造成層與層之間的相互影響**  >[danger] ##### 使用分層解決 * **通過分層來拆解問題**,文章中的例子，在做Http 向服務端發送字符串這個過程中，需要`創建連接`、`發送字符串`、`關閉連接`，三個過程面向過程編寫這三種情況中每一層都會有屬于自己的一些所在層的問題，將每一層的問題拆解，分析去簡化。**代碼分層本身就是一種拆解復雜問題的好方法** * **通過分層來提升代碼可擴展性**，可以將復雜的邏輯切分為多個層，這樣大問題就變成了多個小問題，**組件自身的復用性也就提高了** * **容易做服務的橫向擴展** 總結：**實現責任分離、解耦、組件復用和標準制定**，缺點，**開發成本變高**：因為不同層分別承擔各自的責任,**性能降低**：請求數據因為經過多層代碼的處理,* **代碼復雜度增加**：因為層與層之間存在強耦合，所以對于一些組合功能的調用，則需要增加很多層之間的調用。 >[danger] ##### 分層的設計 認知規則：其上，面向用戶的體驗與交互；其中，面向應用與業務邏輯；其下，面對各種外部資源與設備。在進行分層架構設計時，我們完全可以基于這個經典的三層架構，沿著水平方向進一步切分屬于不同抽象層次的關注點。因此，分層的第一個依據是基于關注點為不同的調用目的劃分層次 >[danger] ##### 文章引用 [一篇文章讀懂分層架構](https://zhuanlan.zhihu.com/p/40353581) [趣學設計模式](https://kaiwu.lagou.com/course/courseInfo.htm?courseId=710#/detail/pc?id=6864) >[success] # 代碼的工程思維 **軟件開發過程 = 定義與分析 + 設計 + 實現 + 測試 + 交付 + 維護**，不能**在軟件開發時，我們總是容易太過于關注局部，而沒能跳出局部去看整體**。**軟件開發 ≠ 軟件編碼** * **有效溝通**現在有一個問題需要解決，問題現象是 xxx，業務方的預期是 xxx，實際看到的是 xxx，不符合預期，從日志和報錯看可能是 xxx 出問題了。由于 xxx 項目上線時間緊迫，急需解決，在線等 >[danger] ##### 文章引用 [趣學設計模式](https://kaiwu.lagou.com/course/courseInfo.htm?courseId=710#/detail/pc?id=6864) >[success] # 評判代碼好壞標準 評價代碼質量的好壞通常有三個維度：**可讀性、可測試性以及可維護性**，可讀性是最重要的，只有你寫的代碼可讀性高，別人才更愿意維護你的代碼；如果可讀性低，大多數人的做法要么是重構，要么是重寫。而重構則意味著要承擔維護這部分代碼的責任，如果不是迫不得已，一般沒人愿意承擔未知的風險，所以實際上對于難以閱讀的代碼，絕大部分人都寧愿選擇重寫而不是重構。 ***** 維護代碼的時間遠遠大于編寫代碼的時間 * **代碼易維護**,在不破壞原有代碼設計、不引入新的 bug 的情況下，能夠快速地修改或者添加代碼 * **代碼不易維護**,修改或者添加代碼需要冒著極大的引入新 bug 的風險，并且需要花費很長的時間才能完成 如果代碼分層清晰、模塊化好、高內聚低耦合、遵從基于接口而非實現編程的設計原則等等，那就可能意味著代碼易維護。除此之外，代碼的易維護性還跟項目代碼量的多少、業務的復雜程度、利用到的技術的復雜程度、文檔是否全面、團隊成員的開發水平等諸多因素有關 ***** 軟件設計大師 Martin Fowler 曾經說過：“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”翻譯成中文就是：“任何傻瓜都會編寫計算機能理解的代碼。好的程序員能夠編寫人能夠理解的代碼。” * **可讀性**,代碼是否符合編碼規范、命名是否達意、注釋是否詳盡、函數是否長短合適、模塊劃分是否清晰、是否符合高內聚低耦合等等，**代碼注釋需要額外的維護成本，往往一段代碼被多次改動后，注釋卻沒有被同步更新，所以盡量避免寫注釋，代碼本身就是注釋**。如果你的同事可以輕松地讀懂你寫的代碼，那說明你的代碼可讀性很好；如果同事在讀你的代碼時，有很多疑問，那就說明你的代碼可讀性有待提高了 ***** * **可擴展性**代碼預留了一些功能擴展點，你可以把新功能代碼，直接插到擴展點上，而不需要因為要添加一個功能而大動干戈，改動大量的原始代碼 ***** * **靈活性**,原有的代碼已經預留好了擴展點，我們不需要修改原有的代碼，只要在擴展點上添加新的代碼即可,實現一個功能的時候，發現原有代碼中，已經抽象出了很多底層可以復用的模塊、類等代碼，我們可以拿來直接使用,如果這組接口可以應對各種使用場景，滿足各種不同的需求，我們除了可以說接口易用之外，還可以說這個接口設計得好靈活或者代碼寫得好靈活 ***** * **簡潔性**,用最簡單的方法解決最復雜的問題 ***** * **可復用性**,盡量減少重復代碼的編寫，復用已有的代碼 ***** * **可測試性** >[danger] ##### 文章引用 [設計模式之美](https://time.geekbang.org/column/article/160991) >[success] # 代碼重構 隨著需求的變化，代碼的不停堆砌，原有的設計必定會存在這樣那樣的問題。針對這些問題，我們就需要進行代碼重構。重構是軟件開發中非常重要的一個環節。持續重構是保持代碼質量不下降的有效手段，能有效避免代碼腐化到無可救藥的地步 雖然使用設計模式可以提高代碼的可擴展性，但過度不恰當地使用，也會增加代碼的復雜度，影響代碼的可讀性。在開發初期，除非特別必須，我們一定不要過度設計，應用復雜的設計模式。而是當代碼出現問題的時候，我們再針對問題，應用原則和模式進行重構。這樣就能有效避免前期的過度設計 * 重構的目的（why）、對象（what）、時機（when）、方法（how） * 保證重構不出錯的技術手段：單元測試和代碼的可測試性 * 兩種不同規模的重構：大重構（大規模高層次）和小重構（小規模低層次）, **大重構 系統結構層面的重構、具體邏輯實現層面的重構 小重構 不符合編碼規范的代碼改為符合編碼規范的代碼（可以通過自動lint工具避免小重構）**