《洞察設計模式的底層邏輯》讀後感

原文： https://mp.weixin.qq.com/s/qRjn_4xZdmuUPQFoWMBQ4Q

學以緻用

文中提到：

• 設計模式的底層邏輯是：“找到變化，封裝變化”。設計模式的基石是面向對象。
• 學習設計模式的目的不是畫出各種設計模式的類圖，而是要學習它的思維：找到變化，封裝變化。
• 設計模式還是要應用到實際的業務中才能發揮它的價值

短短幾句話，卻句句珠玑。

再延展來講，學習的目的在于學以緻用而不在于理論本身，此外我們學習一些技術時更重要的是學習其核心的原理而不是形式。

就像我們不能盲目的追逐技術本身，而是要用技術來解決問題，進而創造價值。

想做到學以緻用，我們要完成思維的轉變，克服原有以記憶或者熱衷技術本身的慣性思維和學習方式，學技術時了解場景，熟悉優缺點，懂得某些技術的核心原理，甚至抽象出最本質的目的。

歸納和演繹法

文中提到歸納法和演繹法，這一點深有感觸。

我們看到的很多文章更多地是在傳遞資訊，而隻有經過抽象和歸納過的精華才叫知識。

之前就對性能優化這一塊通過歸納法進行學習，得到一些自己的思考。

如：

• 性能優化是為了：解決追求良好的使用者體驗和有限資源之間的沖突。
• 性能優化的核心思路： 開源和節流外加限制，即使用更多的資源，減少不必要的浪費，此外加一些限制條件

性能優化常見的一些方法：同步轉異步、串行轉并行、空間換時間(緩存、預熱等)、壓縮、對象池模式、減少上下文切換、減少IO操作、降低沖突的範圍、随機讀寫轉順序讀寫、選擇适合的資料結構、産品層面加限制等都符合上述核心思路。

演繹法也非常重要，我們學習知識不在于死記硬背，而在于學以緻用，所謂的學以緻用更多地講内化和知識的遷移運用能力。

如我們歸納了性能優化的一些思路，再反向再去了解 MySQL、HBase 中一些性能優化的設計背後的原因就會容易很多，平時做技術方案如果考慮性能優化的話也更容易信手拈來。

知其是以然

之前也讀了很多書，總是讀完就忘，或者單純問能夠答出來，但是實際工作生活中卻理論和實踐的脫節，無法靈活運用。

現在讀書思路有些轉變，主要去思考為什麼這麼設計，這麼設計帶來什麼好處等，能能夠從書中得到自己認為最核心的思想，等開發中遇到類似的場景就更容易提取和使用。

跳出慣性思維，以終為始

文中提到的一種現象自己深有感觸：“平時我們在做業務需求開發時，要有這種識别變化的意識，先不要陷入面向過程的思維中，不要一上來就考慮如何去實作，而是思考它是什麼，會有哪些變化”。

想到工作中之前一個 TL 講到：我發現很多人就是需求翻譯機器，拿到項目之後就去設計表，而不是思考價值、目的，不去思考領域。

越來越多的人記住了解決辦法，卻忽略了做某些事情的目的，某些技術的本質。

而且工作過程中越來越發現，越是優秀的老員工，越是有很好的抽象能力，全局視野；越是職級高的同僚，越能夠從全局去思考和看問題。

抓住問題的核心，以終為始，從更抽象和全局的視角看待問題，才能容易真正掌握住變化。

簡一律

文中提到店鋪類目設計的案例，不同方案的權衡依據總結的非常好：能簡單就不要搞複雜，用簡單的技術方案實作就不要用複雜的技術方案。

同時衡量一個人是否真正了解一個知識點的标準也是能否用通俗易懂的語言表達出來。

這也就是所謂的“大道至簡”。

面向未來程式設計

工作編碼過程中，我們通常會面向失敗程式設計，考慮參數合法性，考慮各種異常場景。

在這裡還要提到面向未來程式設計，所謂的面向未來程式設計是指針對未來可能的變化事先做出一些準備。

所謂的發現變化，封裝變化，某種程度上來說就是面向未來程式設計。

如果未來一定不會發生變化，那麼費勁地去發現變化，去封裝變化為了啥呢？

是以封裝變化就是為了在我們預測到的變化地方發生了變化時，能夠減少工作量，降低複雜度等。

和“人無遠慮必有近憂”、“未雨綢缪” 講得道理都是一緻的。

讀經典

文中關鍵的依據都引用自一些經典的圖書或者軟體領域的理論。（這本身就是對這篇文章作為一個案例的抽象）

比如設計模式一書中提到“找到變化，封裝變化”。

我們要做的是學習作者學習的模式。

比如我們讀“任何計算機科學領域的問題都可以通過增加一個間接的中間層來解決”。

那麼我們再看各種緩存機制，兩階段送出、分布式協調元件、分庫分表中間件、消息隊列、領域驅動設計等這些看似完全不想幹的概念卻有着莫名的内在聯系，他們其實都是通過增加中間層來解決各種問題。

如通過增加緩存，解決對讀的速度要求；通過消息隊列實作削峰、解耦；通過增加協調者，實作分布式事務；通過添加領域層隔離變化實作更好的内聚性；通過新增代理層，解決分庫分表的複雜度。

通過這種方式我們可以從更抽象的層次來看到不同技術之間的聯系，更容易了解和認同一些經典理論的說法。