如何减少因原有系统主体功能模块调整带来的高风险？

 

　     这一阵子还是相对紧张一些，主要的工作就是对原有系统进行一次脱胎换骨的流程变动，由于此次变动涉及到数据库结构的较大变动，因此，主要的工作流程改动很大，既然是主要的工作流程，其对系统的影响范围肯定是大范围的，对开发和测试都是一项考验，在这段紧张的工作过程中，自己也在不断地思考，如何尽可能地降低类似情况的高风险，以便能在限定的时间内，在不影响团队成员士气的前提下，准时，甚至提前完成工作任务？

 

概括性地分享一下我们团队采取的措施，以及自己的一些想法：

 

（1）         发动全体成员集中对此次修改涉及的范围和影响进行评估：主要从工作内容的难度及工作量两方面着手，集中后经过讨论，最终按优先级将技术难点及工作内容进行合理分配，此时，按照成员对系统不同模块的熟悉程度进行分配，效果可能会更好，因为我们要尽一切可能来降低项目风险。

 

（2）         与领导或项目接口人讨论并明确工作时间进度表：说来说去，时间都是一个最重要的资源因素！但往往领导或者项目接口人都希望工期的时间越短越好，这恰恰与我们最终的开发和测试团队的希望是相反的，于是，如何争取足够的时间，对于我们顺利开展工作意义非凡！有了前面的内部评估，我们完全可以明确此次调整将造成的影响点和涉及范围，并通过向领导或接口人强调这些关键点，来为我们争取宝贵的时间，一般情况下，我们应该有个底线时间，在此基础上去争取处理紧急情况的机动时间，机动时间对于项目的健康状况是非常重要的。

 

（3）         合理安排工作顺序：首先是顺序，同一件工作，采取的顺序不同，其结果可能也会相差很远，就此例而言，从数据库结构到数据访问层、业务逻辑层及UI层都要进行调整，鉴于新建和修改是有很明显的区别的，建议从基础的数据库结构开始改起，在明确了数据库结构的调整并排除掉一些设计问题后，应尽快将数据库结构稳定，这也算是一切工作开始的基础！然后是，调整UI界面的内容，可以采取先勾画整体面貌，但不实现其后台功能的方式，然后再进行逻辑层和数据访问层的调整！

 

（4）         谨慎处理改动模块：修改不同于新建，尤其是设计主流程的改动时，其涉及的内容一般会很多，这就要求我们谨慎地处理原有流程，在尽可能复用原有代码的情况下，来调整整个功能流程。千万不要采用对原有代码全部推倒重来的方式，当然，也不能对原有代码有过多的依赖，之所以不建议推倒重来，是因为工期一般限定的比较紧，不会给予我们足够宽裕的时间去重构，而过分依赖同样会束缚我们的思路，导致我们要处理各种错综复杂的内部逻辑，同样会浪费我们大量的时间！这里需要我们多用心读读历史代码，对于自己不能十分了解的代码块，尽量要减少修改量，对自己添加的新的代码，一定要注意添加完整的注释。对于原有函数的修改要在保证其他引用不受影响的情况下进行，否则请添加重载进行处理。

 

（5）         尽快跑通主流程：起初自己还不是太明白这步的重要性，但是在跑通主流程前后，自己的心态发生了相当大的变化，修改需要牵扯我们很大的精力处理原有代码，同时还要思考新代码的思路、应对各种情况的处理等等，很容易出现力不从心的情况，这时，我们急切需要一点“成功的证明”，而将主要流程跑通就有这样的一个效果，之后，我们主要来围绕主流程来完善和补充，这样和面对一个完整的大流程来说，潜意识的压力就一下子小了很多，或许，这也正是细化目标的优势所在吧。

 

（6）         清理系统的垃圾代码：经过我们大刀阔斧地修改，一定会产生很多的无用老代码，这样的代码如果任由其存在，对于我们今后的维护工作将是一个大麻烦，其实道理也很简单，有用的代码都要消耗我们很大的精力去理解，再加上这些迷惑性很强的老代码，复杂性就不言而喻了。

 

（7）         稳定主体功能模块：这也是我们修改的一个可视性很强的目标，必须得到保证，才能够进行下面的优化调整阶段，否则，我们的麻烦会非常大！

 

（8）         高频率bug修复：相对于一般开发周期的bug修复期，这个阶段需要的测试强度更大，因为改动涉及的内容和范围很大，尽管主体流程已经基本完成调整，但很容易出现一些功能死角，即一些小的功能点，这个时候，需要我们全部参与到自由测试中去，尽可能多地发现bug，并进行修复。

 

 

            　　经过上面八个步骤的工作，我们的此次调整基本也算是进入到可控范围内了，大家的工作状态也从紧张中稍微得到了一些缓解，仅仅是个人的一些浅见，希望能对大家有所帮助！并环境大家一起探讨更好的方法。