在六年半的开发和管理历程中，曾经做过这样的两个项目，都是步履维艰、越做越增添无力感的项目，现在回想起这两个项目，原来有那么多的相似点，而且原来从开始到结束都已经处处透露了危险的信息，只是在初期并未察觉，将危险讯号说出来，让大家能引以为戒。
这两个项目的共同危险点是：
（1）二手项目：都是5、6年前开发完成的项目，新系统的目标是用新平台实现旧平台相同的功能。
（2）开发文档不全：第一个项目之前是C/S结构，使用dephi编写，只有一份代码众多的dephi编写的源代码，涉及到业务逻辑的部分都封装在tuxedo中，数据库不用改造，数据库操作逻辑部分依然调用之前的tuxedo业务。第二个项目使用甲方的呼叫平台编写，该平台功能不够强大，在所有涉及到数据库操作的部分都调用由其开发人员编写的SQL Server存储过程，可以拿到甲方的文档有：数据库说明文档、存储过程源码、呼叫流程（发现已经有一段时间没有同步更新）、简易的需求文档。
（3）需求不明确：第一个项目没有明确的说明文档，为数不多的知道这个项目的人也只能说个五五六六，需要通过他们安装好的C/S系统来了解，甚至要通过源码来了解。第二个项目有简易的需求文档，但年久未更新，而上线的系统却一直在更新，只能提供不够完全的参考。
（4）之前开发人员的流动：第一个项目之前的甲方开发人员都已经走得七七八八，剩下的1、2个知道点情况的人也已经是从前任的前任手里接过来的项目，现在没有正在运行的旧系统。第二个项目虽然情况好点，但知道项目总体情况的人也寥寥无几，但是现网在全国80来个点都有旧系统在运行。
（5）都需要变更平台：第一个项目数据库结构不需要变更，但平台需要变更，由dephi->Java，我们项目组无人学习过dephi。第二个项目之前采用甲方的呼叫开发平台 + SQL Server存储过程，新系统采用我方的呼叫开发平台，该项目甲方还需要变更数据库，从SQL Server变更为Oracle，并且有很长一段时间两套系统要并行，因此不但涉及到要割接数据，还涉及到两边数据库的双向同步。
第一个项目从头到尾都做得苦不堪言：工期紧张（貌似是2个月还是3个月）、项目组成员有几个是新员工、dephi的代码被甲方的开发人员写得晦涩难懂，周旋于一个源文件4000、5000行的dephi代码当中，而且甲方要求甚多，又不能提供良好的支持，项目组成员被摧残得“花容”失色，而且经过日复一日的加班加点让项目组成员流失惨重，经过延期、延期再延期，最后不出所料的以失败收场。
现在如果来总结这个项目，如此多危险信号的项目就不应该签约，这个项目的如此种种，注定了他是一个铁定会失败的项目。甲方开发人员甚多，有若干Java的开发人员，却想交给第三方公司使用 Java来实现，从这里也可以看出这个项目并没有如甲方前期所说的那样是个不难应付的项目。可惜我等开发人员常常没有做不做这个项目的权利，合同已经签在那里了，只能提供做的过程中的参考意见，sigh……
第二个项目相对要好些，虽然暂时还没有交付，但是交付的可能性还是很大的，但是现在已经延期了2、3月左右，在后期很大一部分开发工作都放在割接和同步方面，与甲方的存储过程开发人员（也是甲方对该系统最了解的人员）J君交流时，我们私下认为：“这个项目最大的失误在于当时没采用同样的数据库结构，而导致给割接、同步和项目开发造成不必要的麻烦。” 而这个失误的造成是由于项目前期双方没有人对割接、同步的问题引起重视，而将精力都放在系统的开发方面，当时由上头决定了采用新的数据库结构，前期在我方数据库结构出来之前，甲方都没有提供当前系统的数据库说明文档。
这个项目越到后期做得越步履维艰，为了避免重犯这样的错误，总结如下，希望涉及到割接、同步、新旧系统并行的朋友开发时引以为戒：
（1）如果旧系统数据库设计合理，不要动修改数据库结构的念头，那将是自讨苦吃。因为如果是同样的数据库结构，即使新旧系统采用的是不同的数据库，割接、同步等都可采用数据库方案，即使数据库层面无法实现，也有很多开源的程序能够实现。但如果异库、异构、同步，那将是极其耗费工时，并且麻烦的工作。
（2）如果相对数据库进行优化，可为系统制造第二期计划；
（3）抱着不想看旧系统业务逻辑代码的想法都是过于理想、不现实的。这个项目我是前期的后半段加进来的，之前的核心开发人员对甲方的开发人员说：“我想最坏的情况就是要看你的业务逻辑源码才能实现新系统，这是一份耗时耗力的工作。前期我尽量将你们实际的需求和注意的点都挖掘出来。”前期确实在需求上下了很多功夫，但是真正投入开发后才知道，了解程度远远不够，很多之前的存储过程因为年久未作修改，当时了解时甲方的开发人员都说得有异议。最后在项目后期还是落得去核对甲方的存储过程来确认是否自己的开发过程有细节遗漏。
（4）不要幼稚到将一个已经运行了近6年、一直在增加和修改需求、并且在中国各地都分布运行、甲方若干能力还不错的开发人员维护的系统想象得过于简单。若干的地区个性化需求（有的需求甚至一点都不合理）、长久积累的灵活性功能等等，会让你相信“没那么简单”。
纵观这两个项目，为何做得如此步履维艰？是否做过类似项目的你也有过这样苦不堪言的体会？笔者所做过的其余多个全新系统，好像还没遇到过开发得如此艰难险阻的。希望看到此文的技术同仁们，万一不得已遇到类似的项目，千万不要想得过于简单吧！重视它，是成功的第一步！
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/