解耦和不解耦

01-30

設計框架，在解耦和不解耦上是個兩難。解耦呢，你面對巨大的競爭，因為別人隨時可以取代你，不解耦呢，別人覺得你在綁定，從一開始就考慮不用你。

想明白這一點，我們就知道，是否解耦，在構架設計上不是關鍵判斷條件（就是說，「架構思考」這個「程序」的if不是寫在這個條件上的）。

丟開很腦殘的人為增加的無必要的介面，解耦的方法是減少交互，減少交互的方法是減少功能。比如說一個內存分配演算法，我們需要的介面可能主要是兩個：

malloc()

free()

這是使用者需要的唯一功能，但像某些庫那樣，如果我們加上

remalloc()

這個功能可以為我們的競爭力取得一定的優勢，特別是對於那些動態包長的協議，它給了內存分配演算法一個hint：如果你反正都預留了空間，不妨把那個空間一起給我。這個特定的內存演算法就會變得「更加」不可替換了。

這上面的考慮，就像用一條不怎麼堅固的繩子拉一輛沉重的車，太用力繩子會斷，不用力車不會走，走起來了就越不容易斷。所以我們一路都要小心翼翼，並沒有一定的方法。

我經常談這些「並沒有一定的方法」的方法，因為理解一個問題的解決並沒有一定的方法，本身就是解決問題的一種方法。

對於戰略來說，對結論只有兩種判斷：

有明確的方法：這在操作上應該摒棄所有其他表相，什麼都不想，一根筋向這個方向沖。好比短跑比賽，你已經肯定路上不會有行人過馬路，你就不要再左右看了，向一個方向跑就對了。而所謂明確方法，有時可以是很有風險的，比如你被人追砍，被追上立馬砍死，在路上被車撞到了，也是必死，這時也不要糾纏那麼多，一根筋跑就對了。這就是戰略判斷的價值，可以大幅降低你執行層面的成本。

沒有明確的方法：這在操作上應該小心翼翼，因為並沒有一定的方法，我們在操作上必須採用「節省」成本並能實現眼前目標的策略。

所以，戰略判斷某件事情沒有明確的方法，也是重要的戰略判斷之一。它的必要性毫不遜色於有明確方法的戰略判斷。

回到解耦還是不解耦這個問題。從設計思路上說，必須解耦，或者說基本功能保持最小，是肯定的。不斷增加功能實現綁定，這種增加必須基於競爭力，否則只會限制競爭力，給競爭對手可乘之機。這是在過程中的「小心翼翼」，一個軟體框架的成長，就是在環境的不斷變化中，能否度過這個小心翼翼，最後，把大部分人都綁到戰車上，成為一個越滾越大的雪球。這種情況下，除非環境產生巨大變化，否則它就已經無懈可擊了。

所以，對於一個框架來說，構架，介面如何發展，完全被具體細節控制著，並不是你想不想解耦，是不是和對手對著干，是否開源等問題可以左右的。那些細節之外的每個獨立考量，都會影響框架的競爭力，而不是無足輕重。

但我這個散文想討論的不是怎麼做解耦設計這個問題，而是從競爭的角度討論如何擊敗一個已經成熟的框架的。

我們很多時候對對手做戰略判斷（特別是對於一些不直接做技術的管理者來說），我們看到的是特性。但當我們討論「特性」的時候，我們已經忽略了細節了。沒有經過時間打磨的「特性」，和經過時間打磨的「特性」差距是很大的，這就是我前面談到那個不斷增加「細節」的過程。過去我們簡單用一個匯流排Lock，就可以實現spinlock；現在我們用exclusive的load和store來讓有互鎖關係的兩個CPU核自己進行Cache同步；很快呢我們又會用……——好吧，這個技術未發布，我們晚點談——所以，我們談對手有什麼，而我們必須有什麼，這是必死的路線。

當我們談競爭的時候，我們總是著眼於競爭對象有什麼功能，然後想著提供一樣的功能，希望可以追趕它。但從戰略的角度考慮這個問題，這顯然是最差的路線，這為自己戰略上營造了一個吃虧的競爭的條件。

更合理的方式是，使用和對方一模一樣的解決方案，然後拋棄掉在對方成長過程中在試探過程中明顯走錯的路線，從而形成一個沒有包袱的解決方案。這樣雙方才在相同的起跑線上。然後再去比誰對新環境的敏感性更好。

當我們用這樣的方法來建立平台後，剩下的就是如何選擇目標市場的問題了。如果這個問題沒有解決，無論是繼續學習對手，還是選定目標市場，都顯得毫無意義。