架構腐化之謎
本文的內容來源於此，但非僅限於此:http://www.infoq.com/cn/articles/cjz-architecture-corruption
本文13年10月完成的，在13年底-14年初負責一個營銷項目的業務代碼架構，卻並未完全按照下面的優點做下去（太汗顏了~\(≧▽≦)/~）：例如監控只加入了一半、單測只完成數據訪問層部分、部分無用代碼還未清理重構。。。當然3.8日的deadline下，人員、時間這些剛性資源的影響很大，只能靠之後來彌補。話說：知行合一方是王道，知易行難纔是常態( ⊙ o ⊙ )啊！
失敗的經驗更容易讓人記住，是因爲失敗讓人印象更深刻，5年的編碼經歷，大部時間都是在循環搞一些讓人胃疼的東西。
腐化的特徵
每個項目初創之時，都有一個目的：理念先進、架構優美、編碼簡單、易於維護，但往往隨着進度的推進，因爲各種原因會變得難於理解、維護、擴展。我曾參與2個遺留產品：關於支付、社交的，在我加入的時候已經只能添加新的功能代碼，老的分支邏輯：無論是否有用，都沒有人敢動。
- 難以修改：代碼牽涉模塊流程太多，導致任何的改動都會造成依賴業務的動盪。如果需要在現有流程的基礎上新增業務，最安全的方式是通過if-else方式來兼容老業務添加新功能，而且木有單測，只能靠迴歸測試來保證功能不出錯。這也是我參與支付、社交產品遇到的最常見問題，當時的感覺是自己唯一能做的就是避免新的功能代碼把這工程拖向腐爛的深淵，但每次做局部優化也會心驚膽戰。
- 難以模塊化：模塊化的目的是重用：代碼、功能。早期的遺留系統很容易出現package之間的交叉應用、循環應用，後面即使想重構如果沒有能力和支持，基本上是不可能的事情-把事情做錯比最對容易多了。所以現在這2個系統只是處於線上運行狀態，基本上沒有添加大的功能模塊了。
靠譜的規則
在一個項目開啓的時候，靠譜的編碼規則（copy from my workmate）：
電影的業務邏輯服務化，整合無線和pc端的業務邏輯。達到幾個目標點：
- √ 業務模型統一
- √ 業務接口整合
- √ 異常體系定製
- √ 接口可測試化
- √ 系統可監控性
- √ 提高開發效率
這些規則在任何項目中都適用，個人認爲業務模型可以劃分爲：元數據模型和業務數據模型。元數據模型是現實數據的邏輯映射，例如電影系統中的排期、影院、影片信息，面向db。業務數據模型面向系統頁面展示而用，頁面的變化、調整會導致業務數據更改，但是組成業務數據的元數據不會更改：
微信：比如朋友圈這個產品經歷了很多次變動，出了好幾十個版本，但是有東西是不變的，就是數據模型是不變的。所以我們在產品設計和細節還沒出來的時候，我們從後臺到協議設計到本地存儲的整個數據結構設計都已經做好了，界面的框架也可以先做，等設計最終確定的時候，我們技術這邊已經進入ready的階段。（http://www.huxiu.com/article/23367/1.html）
我理解所謂的ready階段是指：交互和原型確定的時候，後臺只需要使用基本的數據結構提供相應的業務數據就ok了。
業務接口整合：現在系統都會有app和pc版，每個版本依賴的基礎服務接口應該是統一的，這也要求app和pc上的設計的產品模型不能有太大差異。太多的業務分裂也會導致滑向深淵。
異常體系定製、系統可監控性、提高開發效率：不要用if-else-return error 的方式來處理異常分支，統一的異常體系更易於主流程編碼、維護。監控是一種非功能性的需求，但是要趁早規劃、實現，一個運行在黑盒狀態的系統是不能令人放心的。提高效率和編程理念、使用的平臺、工具、框架有關係