支付平台项目的小结

一个多月的时间，终于把支付平台这个阶段性项目release了，经过几天的bug fix 已经基本趋于稳定。期间发生的许多事情值得记录和总结。

项目的数据复杂度比较高，数据库的重新设计与迁移是痛苦的。为了保证不影响运营，采取了保守的写2边的做法。

 

项目采取的步骤：

1. 在没有任何文档的情况下，查找所有涉及到要迁移的表的功能。以文件的方式查找asp页面，存储过程。（痛苦的经历）
2. 总结查找到的功能与在线的功能对比，到底哪些还在继续使用，哪些功能不用了。（没文档的痛苦.too)
3. 功能重写讨论，分解工作任务，讨论数据新的数据流向怎样集成到现有功能中
4. 开发，期间对于数据库的操作反复讨论，几乎结对编程。
5. 测试，期间导款功能返工，原有代码极为混乱，改动难度很大造成。
6. 部署后的bug fix,期间业务部门提出了功能不好用以及新需求。

 

总结：

1. 文档的重要性，对于后来者以及系统重构的意义。
2. 数据库的混乱。测试环境与正式环境的字段差异导致在测试时无法发现问题，上线时异常。
3. 个人觉得对于一个业务复杂的交易平台。数据库的重要性不言而喻。怎样开发、测试、上线呢。以下是最基本的保证。
• 开发库：开发人员基于的数据库环境。此环境中，可以根据新的开发需求，更改和新建数据库库，表，字段。当开发完成后，通知DBA把测试环境和正式环境的数据库更新
• 测试库：应该保证测试库与正式库的一致性，才可以保证不会再上线时出现数据库差异导致的错误。
• 正式库：生产环境的DB。
4. 产品经理存在重要性，即使是数据迁移这类的项目，也需要有一个产品经理与开发经理，业务部门的沟通，产生最终产物PRD。
1. 有些功能在数据迁移时，用户操作界面不得不更改。例如财务导款。
2. 开发经理在性能上控制上进行把握，产品经理基于此把一些业务部门的需求屏蔽掉，或讨论采取其它方式实现。
3. PRD的详细程度。其中应该包括压力需求。例如：要把2w条的数据一下导入的问题，事先开发人员不清楚。
5. 功能模块的Design文档。应该严格要求必须先根据PRD撰写设计文档，包括页面处理逻辑，数据处理逻辑，使用的相关数据库。
6. 尽量避免开发组人员与业务部门直接沟通。业务部门的需求总是无穷尽的，开发人员直接参与不会有任何结果。需要产品经理的控制。
7. 代码的版本管理。主干和分支的模式需求在这次开发中产生，在支付平台开发的过程中，另外一个项目也同时要基于底层类库开发。导致了上线时间的依赖关联问题。
8. 导款的重写，是在项目进入到测试阶段才发生的，开发人员连续加班4-5天才搞定这个问题。对于项目控制来说，这是很危险，应该尽量避免的，进一步验证了把原功能逻辑直接拿过来重写的方式是不推荐的。

 

目前只想到这些，项目还是按时release了。虽然有一些不如意的地方，这也是每个项目进行中不得不遇到的事情。

工作，工作流程，配置，协调，软件开发流程中的每一部份，都很重要，任何公司，组织都只能结合自己的情况一步一步优化。当然先进的流程模型敏捷开发，SCRUM ，MSF敏捷也许是经验总结之外的一个很好的借鉴。