什麼是耦合？
耦合，是架構中，本來不相干的**、模組、服務、系統因為某些原因聯絡在一起，各自獨立性差，影響則相互影響，變動則相互變動的一種架構狀態。
感官上，怎麼發現系統中的耦合？
作為技術人，每每在心中罵上下游，罵兄弟部門，「這個東西跟我有什麼關係？為什麼需要我來配合做這個事情？」。明明不應該聯動，卻要被動受影響，就可能有潛在的耦合。
因為公共庫，導致相互受影響，就是乙個耦合的典型案例。
場景還原
乙個看似「公共」的業務庫(*.so *.jar *.dll *.php)，很多業務系統都依賴於這個公共庫，這個庫使得這些系統都耦合在了一起。
耦合如何導致相互影響？
業務1，業務2，業務3都依賴於某乙個biz.jar，業務1因為某個需求需要公升級biz.jar。上線前，業務1的qa進行了大量的測試，確保無誤後，**發布，發布完線上驗證無誤後，上線完成，閃人。
突然，bug群裡有人反饋，業務2的系統掛了，業務3的系統也掛了，一下炸開了鍋：
業務2的大boss首先發飆：「技術都幹啥了，怎麼系統掛了」
業務2的rd一臉無辜：「業務1上線了，所以我們掛了」
額，然而，這個理由，好像在大boss那解釋不通…
業務2的大boss：「業務1上線？業務1上線前測試了麼」
業務1的qa自信滿滿：「測試了呀，上線前上線後都驗證了，沒問題呀」
業務2的大boss對業務2的rd吼道「還想甩鍋，拖出去祭天」
不知道大家工作中會不會遇到這樣的場景，因為公共庫的耦合，兄弟部門上線，影響的確是你，此時你心裡可能就在罵娘了，這幫不靠譜的**隊友。
特別的，如果公共庫的使用方很廣，這個耦合很嚴重，可能影響很大的範圍。
如何解除公共庫耦合？
方案一：**拷貝乙份
別嘲笑這個方案，誰敢說自己寫**的時候沒這麼幹過？
我們都知道這不是乙個好的方案，但不可否認，拷貝之後，**各自演化，乙個地方公升級出錯，只影響一方，拷貝方只要不動原有**，至少是不會受影響的。
**拷貝缺點很多，系統拆分時，萬不得已不要使用這個方案。
方案二：垂直拆分，將公共庫里業務個性化的**拆到呼叫方去，不要放在公共庫里
需要把業務個性的**拆分到各個業務線自己的工程，自己的業務庫里去，例如s1.jar / s2.jar / s3.jar，修改各自的**，至少不會擴大影響範圍。
大家為什麼都把**往乙個公共庫里塞？
很多時候，因為惰性，一點一點的惰性，日積月累，終成大坑。
這個垂直拆分是乙個架構重構的過程，需要各業務方配合。
方案三：服務化，將公共庫里通用業務**拆到下層去
完成了第一步，業務個性化的**提取到業務側上游。
接下來是第二步，業務通用的**，下沉抽取一層服務，服務對上游提供rpc介面：
每次修改底層介面，需要測試介面的相容性，保證不影響舊呼叫方
如果是新的業務，則建議新增介面
最終，達到通過服務rpc呼叫的方式來解除耦合。
有朋友會問：
底層服務介面的測試
上游業務層對公共庫的測試
都是測試，為何前者能控制影響範圍呢？
底層介面，所有人呼叫，介面沒問題則呼叫方都沒問題
上游業務層對公共庫測試，只能保證自己的業務沒有問題，並不能保證其他業務方沒有問題
個性業務**上浮，共性業務**服務化下沉，只是乙個很小的優化點，但對於公共庫解耦卻是非常的有效。
小小的IP，大大的耦合，你痛過嗎？
什麼是耦合？耦合，是架構中，本來不相干的 模組 服務 系統因為某些原因聯絡在一起，各自獨立性差，影響則相互影響，變動則相互變動的一種架構狀態。感官上，怎麼發現系統中的耦合？作為技術人，每每在心中罵上下游，罵兄弟部門，這個東西跟我有什麼關係？為什麼需要我來配合做這個事情？明明不應該聯動，卻要被動配合，...
三正規化的依賴，小小的知識，大大的學問
三正規化使得資料庫的設計變得有據可依，資料庫的冗餘大大減少。然而，三正規化的定義，卻不那麼讓人省心，一堆文字外加數學知識，讓人著實有點小蒙。雖然說完全按照三正規化設計資料庫並不可取，但是要想設計乙個好的資料庫，三正規化的知識是必不可少的。要想更好理解三正規化的定義，那麼了解依賴是必不可少的，了解了這...
寫MFC遇到的各種大大小小的坑
搭建環境 vs2013 mfc120生成器 python3.6 這是乙個記錄了遇到的大大小小的坑，真的是十個裡面九個是坑！這裡是用來記錄我遇到的坑的，當然裡面還有許多未解之謎，我自己也不明白 有cmd命令列註冊，有直接regsvr32 c windows system32 syswow64 msco...