深耕业务 ---- 探索复杂/超复杂前端业务的开发与设计

同步更新博客：

    cnblogs： 深耕业务 ---- 探索复杂/超复杂前端业务的开发与设计

    知乎：深耕业务 ---- 探索复杂/超复杂前端业务的开发与设计

    github：深耕业务 ---- 探索复杂/超复杂前端业务的开发与设计

　　距离上一篇博客，我已经有3个月没有写博客了，脑子里也有很多灵光和新点子，忙嘛，肯定忙，但是忙不是理由，所以见谅。这次给自己下了死命令，一定要产出点东西，so，将自己最近开发中能总结的东西慢慢再搞出一点。

　　　　PS：这是一篇思维参考性的文章，比较枯燥，阅读时间30分钟（包括思考和印证）

　　作为深耕的业务，我们就从一个我遇到的复杂需求开始做个引子。栗子如下（可先看图片过个眼瘾）：

　　需求列表如下：

1. 有20种不同类型的活动，每种活动按钮文字不一样
2. 每种活动根据活动状态有不同的show和hide方案（最多有3-4个字段，分别控制）
3. 根据不同业务状态，定义按钮的展示方式（禁用？ or 可用？）
4. 每个不同按钮的功能都不一样
5. 同一个按钮，根据不同活动也有不同的功能（比如调整优惠，针对不同活动，引用不同组件）
6. 一个按钮，相同的功能，但是请求的接口和参数也是不一样的（老数据老接口，新数据新接口）

 

　　一般要求：这是一个迁移不完整的入口项目，对接所有活动的详情和操作，考虑业务不稳定性（业务变动需要变更，例如新迁移活动需要增加新的操作）以及迭代（继续迁移其他老项目，对接上来），需要考虑到更简易的拓展以及敏捷操作，当然维护和开发的成本也需要考虑的。

 

　　更高要求：

1. view视图上，简洁清爽，各种逻辑判断不乱
2. vm层，避免超繁琐，代码的逻辑和归类清晰明了
3. 低耦合，达到更松散的控制，对于以后拆分和开发更敏捷
4. 轻松的统一管理，可以统一管理

 

　　相信大家看了这个需求和要求，每个人根据自己的程序员开发经验和设计经验上，每个人都有不同的解决方案。其实，每个解决方案都是一种方式，只是在不同角度上的实施的成本以及设计思维上的不同。So，我想分享给大家的，也是经过我思考后以及完善的一种解决方案，拿出来仅供大家参考。

 

　　程序员写的所有代码全