架构腐化之谜

本文的内容来源于此，但非仅限于此: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 的方式来处理异常分支，统一的异常体系更易于主流程编码、维护。监控是一种非功能性的需求，但是要趁早规划、实现，一个运行在黑盒状态的系统是不能令人放心的。提高效率和编程理念、使用的平台、工具、框架有关系