剛工作的時候宴凉，學習并整理了《JavaScript常見設計模式實踐梳理》，那會還運用了一些比較基礎的設計模式在代碼里撩独，比如：模版方法模式、策略模式账月、發(fā)布-訂閱模式，以及裝飾器模式局齿。
最近又重學了一遍設計模式剧劝，復習了“一小時讀完《JavaScript設計模式與開發(fā)實踐》”，學了極客時間的《設計模式之美》抓歼、掘金小冊《JavaScript 設計模式核心原理與應用實踐》担平，再結合自己在寫代碼時的思考，獲益良多。
感覺自己平時使用的較多的還是發(fā)布-訂閱模式挑围，但在一些復雜狀態(tài)粉捻、組件復用的情況下，還是需要更多的設計模式來進行輔助讓代碼的層次得以提升胜蛉，狀態(tài)模式和裝飾器模式很好用。
設計模式之美
《設計模式之美》里用的示例雖然是Java代碼，但是會有一些通用的概念湃窍。對于里面提到的設計原則闻蛀、編程規(guī)范、以及代碼重構都很值得學習您市。
設計模式分類：
我們常把23種經(jīng)典的設計模式分為三類：創(chuàng)建型觉痛、結構型、行為型茵休。
- 創(chuàng)建型設計模式主要解決“對象的創(chuàng)建”問題薪棒；
- 結構型設計模式主要解決“類或對象的組合或組裝”問題；
- 行為型設計模式主要解決的就是“類或對象之間的交互”問題榕莺。
關于重構：
- 我們可以把重構理解為俐芯，在保持功能不變的前提下，利用設計思想钉鸯、原則吧史、模式、編程規(guī)范等理論來優(yōu)化代碼唠雕，修改設計上的不足贸营，提高代碼質量。
- 資深工程師為代碼質量負責岩睁，需要發(fā)覺代碼存在的問題钞脂，重構代碼，時刻保證代碼質量處于一個可控的狀態(tài)笙僚。
- 我特別提倡的重構策略是持續(xù)重構芳肌，就像把單元測試、Code Review作為開發(fā)的一部分肋层，我們如果能把持續(xù)重構也作為開發(fā)的一部分亿笤，成為一種開發(fā)習慣，對項目栋猖、對自己都會很有好處净薛。時刻具有持續(xù)重構意識，才能避免開發(fā)初期就過度設計蒲拉，避免代碼維護的過程中質量的下降肃拜。而那些看到別人代碼有點瑕疵就一頓亂罵，或者花盡心思去構思一個完美設計的人雌团，往往都是因為沒有樹立正確的代碼質量觀燃领，沒有持續(xù)重構意識。
- 不過锦援，保持代碼質量最好的方法還是打造一種好的技術氛圍猛蔽，以此來驅動大家主動去關注代碼質量，持續(xù)重構代碼。
關于編碼技巧：
- 將復雜的邏輯提煉拆分成函數(shù)和類曼库。
- 通過拆分成多個函數(shù)或將參數(shù)封裝為對象的方式区岗，來處理參數(shù)過多的情況。
- 函數(shù)中不要使用參數(shù)來做代碼執(zhí)行邏輯的控制毁枯。
- 函數(shù)設計要職責單一慈缔。
- 移除過深的嵌套層次，方法包括：去掉多余的if或else語句种玛，使用continue藐鹤、break、return關鍵字提前退出嵌套蒂誉，調整執(zhí)行順序來減少嵌套教藻，將部分嵌套邏輯抽象成函數(shù)。
- 用字面常量取代魔法數(shù)右锨。
- 用解釋性變量來解釋復雜表達式括堤，以此提高代碼可讀性。
如何發(fā)現(xiàn)代碼質量绍移？
SOLID原則：
| 設計原則 | 解釋 |
|---|---|
| 單一職責原則 (SRP) | Single Responsibility Principle悄窃，每個類應該只有一個引起其變化的原因，即一個類只負責一個功能領域蹂窖。 |
| 開放封閉原則 (OCP) | Open/Closed Principle轧抗，軟件實體（類、模塊瞬测、函數(shù)等）應該對擴展開放横媚，對修改封閉。即不改變現(xiàn)有代碼的情況下月趟，通過擴展實現(xiàn)新功能灯蝴。 |
| 里氏替換原則 (LSP) | Liskov Substitution Principle，子類對象必須能夠替換其父類對象而不引起錯誤或不良行為孝宗，這樣利用繼承實現(xiàn)系統(tǒng)時穷躁，子類對象就可以完全替代父類對象。 |
| 接口隔離原則 (ISP) | Interface Segregation Principle因妇，客戶端不應該被強迫依賴它們不使用的方法问潭，通過多個專門的接口而不是一個通用接口來實現(xiàn)系統(tǒng)的靈活性和解耦。 |
| 依賴倒置原則 (DIP) | Dependency Inversion Principle婚被，高層模塊不應該依賴低層模塊狡忙，兩者都應該依賴于抽象。抽象不應該依賴細節(jié)址芯，細節(jié)應該依賴抽象去枷。 |
其它設計原則：
| 設計原則 | 解釋 |
|---|---|
| 別重復自己（DRY）原則 | Don't Repeat Yourself，不要重復代碼或邏輯。當某個邏輯需要在多個地方使用時删顶，應將其提取到一個單獨的模塊或函數(shù)中。 |
| 保持簡單（KISS）原則 | Keep It Simple and Stupid淑廊，保持設計簡單逗余，避免不必要的復雜性，以提高代碼的可讀性季惩、可維護性和可擴展性录粱。 |
| 你不會需要它（YAGNI）原則 | You Aren't Gonna Need It，只實現(xiàn)當前需要的功能画拾，不要為了未來可能需要的功能進行過度設計和實現(xiàn)啥繁。 |
| 最少知識原則（LOD法則） | Law of Demeter，一個對象應該對其他對象有最少的了解青抛，只與直接的朋友（相關聯(lián)的對象）通信旗闽，避免和陌生的對象發(fā)生聯(lián)系，以減少耦合度蜜另。 |
| 高內聚 | High Cohesion：模塊內部相關性強适室，所有功能都是高相關的，應當集中在一起举瑰。一個高內聚的模塊通常專注于完成一個單一任務捣辆，能夠獨立工作。高內聚提高了系統(tǒng)的可維護性與可重用性此迅。 |
| 松耦合 | Loose Coupling：模塊之間的依賴關系較少汽畴，每個模塊可以獨立演變和修改而不影響其他模塊。耦合度低使得系統(tǒng)組件之間的變化不會引起連鎖反應耸序，增進了系統(tǒng)的靈活性和可擴展性忍些。 |
| 代碼重構 (Refactoring) | 通過逐步修改代碼結構而不改變其行為，以提高代碼的可讀性佑吝、可維護性和性能坐昙。 |
| 持續(xù)集成 (CI) | Continuous Integration：開發(fā)人員頻繁地集成他們的工作，并自動化測試和構建芋忿，以快速發(fā)現(xiàn)問題和保持高質量的軟件產(chǎn)品炸客。 |
| 領域驅動設計 (DDD) | Domain-Driven Design：以領域模型為核心，通過緊密結合業(yè)務領域和需求將軟件設計分為不同領域戈钢，關注領域邏輯和領域模型的正確性痹仙。 |
| 測試驅動開發(fā) (TDD) | Test-Driven Development：首先編寫測試用例，通過測試驅動開發(fā)殉了，確保代碼實現(xiàn)功能之前要通過測試驗證开仰，提升代碼的可靠性和可維護性。 |
| 行為驅動開發(fā) (BDD) | Behavior-Driven Development：基于 TDD 的一種擴展，通過定義業(yè)務行為和預期結果來驅動開發(fā)众弓，確保開發(fā)過程符合業(yè)務需求恩溅。 |
| 架構風格 | Architecture Style：軟件架構模式的選擇和應用，如 MVC谓娃、微服務脚乡、事件驅動架構等，以滿足特定的設計需求和架構目標滨达。 |
| 用戶體驗設計 (UX Design) | 強調從用戶體驗出發(fā)進行設計奶稠，關注用戶的交互邏輯和界面設計，以提高產(chǎn)品的易用性和用戶滿意度捡遍。 |
| 敏捷開發(fā) (Agile Development) | 通過迭代和增量的開發(fā)方式锌订，靈活應對需求變化，快速交付高質量的軟件產(chǎn)品画株。 |
| 合成/聚合復用原則 | 優(yōu)先使用對象組合和聚合來實現(xiàn)代碼復用辆飘，而不是通過繼承。 |
JavaScript設計模式核心原理與應用實踐
《JavaScript設計模式核心原理與應用實踐》這本掘金小冊污秆，我感覺寫的非常好劈猪，適合前端開發(fā)人員學習和理解，里面的例子很通俗易懂良拼，很容易運用到自己的代碼中去战得。書里還提到了觀察者模式與發(fā)布-訂閱模式的對比，值得大家去好好看一下庸推。
最近看一個RxJS視頻的時候常侦，里面提到了防腐層對數(shù)據(jù)格式進行轉化，我感覺就是適配器模式做的事情呀~
邊寫代碼贬媒，邊思考聋亡，邊重構，這種由學習到掌握到慢慢重獲自信的感覺真棒呀际乘！
