开发项目经验教训

开发项目经验教训

• 针对业务抽象一个业务类（包含所有业务场景，新增场景在此增加逻辑分支）
• 针对不同国家实现不同业务子类（各国家在继承父类所有业务场景逻辑的基础上，各自开发独有的业务逻辑）
• 分离 UI 和 业务逻辑
  • 主程序负责UI逻辑，面向用户，基本通用，改动量小，
  • 业务类负责业务逻辑，负责后台，随新国家和新业务需求变化，改动量大
• 对数据库表的增删改操作封装父类方法，记录操作日志，其他开发只能通过调用方法实现数据变更，禁止直接用modify等数据库操作语句。

业务背景：
由于主程序逻辑复杂

• UI 和 业务逻辑交叉（主程序包含太多业务逻辑）
• 业务场景逻辑分支和国别特殊逻辑分支交叉
  运维和新公司上线时，经常多个需求针对平台中同一个开发对象，导致相互锁定，只能排队处理

问题描述：

1. 开发效率低，运维问题处理慢（多项开发需求无法同时推进，只能排队处理。对后续新公司上线效率影响大，尤其是有外包项目开始后，不同开发之间协调工作将更难处理）
2. 代码阅读理解难度大 （判断不同业务场景分支的逻辑复杂）
3. 新公司，新需求变更，难以形成固定的操作规范，（业务逻辑分支没有完全隔离，新公司、新业务的上线对平台主程序修改内容多，且复杂）

解决方案：针对平台进行重构优化，优化思路如下：

• 针对业务抽象一个业务类（包含所有业务场景，新增场景在此增加逻辑分支）
• 针对不同国家实现不同业务子类（各国家在继承父类所有业务场景逻辑的基础上，各自开发独有的业务逻辑）
• 分离 UI 和 业务逻辑
  • 主程序负责UI逻辑，面向用户，基本通用，改动量小，
  • 业务类负责业务逻辑，负责后台，随新国家和新业务需求变化，改动量大

优化收益：

1. 方便外围系统直接调用（后台提供服务接口，需要封装业务逻辑）
2. 减少后期运维成本，（使用面向对象的代码设计，梳理业务逻辑结构，减少代码阅读理解时间成本）
3. 减少运维和新公司上线新需求开发时间（业务逻辑架构清晰，可直接复用，多项需求可以同时开发，互不影响）
4. 降低代码部署风险（目前业务逻辑都揉在主程序中，逻辑复杂，重构可以隔离不同的业务逻辑，减少新需求变更对现有业务的影响）