版本开发复盘的一封邮件
我们的问题：
1、测试：不知道开发又改了啥，xx测试用例又测试不过了
2、我要改个接口。。。。。对应的模块：接口又改了
3、需求变一下，或者增加一个功能，或者之前一个地方没有想好，然后很多地方都要改
一句话总结一下，改了一小点地方，系统崩溃了，牵一发而动全身
Why and how？
之前我们开发Oms，其实还是相对简单的产品，无所谓订单 商品 库存。
而分销平台的逻辑要复杂多了：分销者 供货商 订单 商品 库存 账单 支付
我们再用之前开发oms的方式显然应付不了分销平台了。之前我们开发产品像搭积木，当产品复杂到一定程度，纯靠搭积木的方法已经行不通了。随便换一块，或者动动位置，整个产品就会倒塌。而现在常见的大型建筑越来越来采用预制组合模块，现场只需要拼接就行，开发复杂软件也是这样。
怎么做？先说原则
1、开放封闭原则：
尽量通过扩展软件实体来解决需求变化，而不是通过修改已有的代码来完成变化
开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。
2、依赖倒置
高层模块不应该依赖底层模块，底层也不该依赖高层，二者都该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象；依赖倒置原则的本质就是通过抽象（接口或抽象类）使个各类或模块的实现彼此独立，互不影响，实现模块间的松耦合。
3、接口最小
模块之间的每个接口应该只做一件事情。而且是最小的事情。
具体的办法：
抽象、抽象再抽象，抽象业务。基于抽象定义接口。针对具体的编码，最简单的套路就是设计模式。
策略模式、工厂模式是我们最常该用到的。
