我一直很認同一句話：架構一定要隨著業務的發展進行演進，所以在著手處理之前，都需要思考4個問題：
架構演進前的4個問題
（1） 本次架構演進為了解決那幾個業務或技術問題？
避免為了炫技而動架構，并且作為本次架構演進是否成功的驗證標準。
（2）解決這些問題是否迫在眉睫？
如果不緊急，那么可以考慮先出方案寫Demo，然后到一定的時間或業務節點在做處理。
（3）除了架構演進外，用別的方案能否起到同樣的作用？
如果可以的話，建議采用別的方案，避免造成結構性的破壞。
（4）需要投入多少人來做，架構演進的邊界在哪里？
我們畢竟是商業公司，不是開源組織，不能不計成本，無休止的進行下去，需要有一個計劃和目標。
基礎組件層抽取
為了清晰的說明以上4點，我們舉個很簡單的例子：最近一次的架構演進是基礎組件層的抽取。作為架構師我們來回答以上4個問題：
（1）本次架構演進為了解決那個或那幾個業務問題？
問題1： 我們目前同時維護兩個APP（更美用戶版和更美醫生版），而兩個APP的很多地方都是很像甚至一樣的（因為醫生版的代碼大部分都是從用戶版拷貝過去的），那么這就造成一下幾個問題：
用戶版發現了一個Bug，那么對應的醫生版的APP也得改，還有可能改出新的Bug。
相同的業務流程做了同樣的修改后，兩邊都需要同步，甚至有的時候，由于分別維護，所以某些代碼已經產生了版本的差異，所以問題就從枯燥的代碼的拷貝粘貼到需要仔細檢查一下業務邏輯，極有可能出錯。
所以我們搭建了基礎組件層，將基礎組件（如：網絡，緩存，公用控件，工具，統計等等）抽取出來給兩個APP進行公用，從而有效解決了問題。
問題2： 由于公司的人比較少，Code Review的力度不夠，所以我們需要將公用控件和底層邏輯在層維護，從Gitlab的權限上進行隔離，保障這部分代碼由經驗豐富的工程師來維護，降低風險。
（2）解決這些問題是否迫在眉睫？
問題1：緊急，醫生版迭代的速度越來越快，如果不盡早進行架構演進，那么問題將會越來越多，以后演進的成本會更大。
問題2：一般，我們的工程師有良好的習慣，一般在有任何底層代碼變更需求時，都會先和架構師進行溝通，避免擅自修改帶來的問題。
（3）如果不做架構演進，用別的方案能否滿足業務需求？
暫時沒有發現別的方案。
（4）需要投入多少人來做，架構演進的邊界在哪里？
大約投入了2個人1個迭代的時間，關于抽取哪些內容，之前已經制定了完整的計劃和目標，甚至我們先抽取出了最常用的網絡層來做可行性驗證。
嗯，看上去確實不錯，4個問題都回答的很好，不過好像還差一塊，架構演進完畢后的一段時間，我們需要從業務工程師那里了解一下新的架構是否真的像自己想想的那樣牛X，所以還有一件事就是架構的使用反饋。 通過自業務工程師的反饋，你不僅可以了解自己的架構是否達到了目標，而且能夠知道自己的架構是否足夠的優秀和接地氣，是的，就是接地氣，可能看上去土但是很實用。
業務組件層
OK，那么我們再嘗試用上面的方式來討論一下我們下一步要做的業務組件化的架構演進
（1）本次架構演進為了解決那幾個業務或技術問題？
目前我們的App的代碼都是在一個工程里開發的，在人比較少，業務發展不是很快的時候，這樣是比較合適的，能一定程度地保證開發效率。
目前業務發展速度倍增，代碼量和開發人員也逐漸增多，這時單一工程開發模式就會顯露出一些弊端：
- 耦合比較嚴重（因為沒有明確的約束，「業務」間引用的現象會比較多）
- 任何人都可以修改任何代碼，分工不明確，容易導致意想不到的錯誤
- 業務方的開發效率不夠高（只關心自己的組件，卻要編譯整個項目，與其他不相干的代碼糅合在一起）
- 團隊規模擴大的時候Git分支增多，提升管理難度
為了解決這些問題，就采取了「業務組件化」策略。它能帶來這些好處：
- 加快編譯速度，只用編譯Example工程和依賴的基礎組件
- 自由選擇開發模式（MVC/MVVM/MVP）
- 自由選擇開發語言（Swift/ObjC/Java/Kotlin）
- 方便 QA 有針對性地測試，沒有改動的業務組件不需要QA覆蓋
- 提高業務開發效率，只需要關心自己的業務
（2）解決這些問題是否迫在眉睫？
看上去還行，雖然目前業務發展速度畢竟快，但是目前團隊人數并不多，代碼量還在可控范圍內，所以目前并不急迫。可以先研究方案，寫寫Demo做做驗證。
（3）如果不做架構演進，用別的方案能否滿足業務需求？
從調研的結果看，這個是目前主流方案，用其他方案是否可行還待進一步論證，好在我們并不著急。
（4）需要投入多少人來做，架構演進的邊界在哪里？
預計需要2個人，3 - 4個迭代的時間，將主體業務都拆分出來，原則上主應用中不應該包含任何業務代碼。
