背景：项目接近尾声，部分人力在完成工作交接后释放到其他项目中，剩余的人完成结项前的维护开发工作。
事件：在交接结束的一个新的迭代开发中，开发工作出现延期，功能上线也出现问题。出现问题的大都是释放的人力所负责的工作。
思考：对交接的代码进行review发现。代码质量不过关，主要有以下问题：
1，编写代码没有按照项目组初期制度的规范进行，基本空格和换行规范没有严格执行。导致代码阅读困难
2，编写代码逻辑不严谨，可能发生的情况考虑不全。导致上线后出现问题。
3，大量重复代码，某一个功能可能只是部分简单逻辑不同，但是其他地方需要调用，直接复制一份，没有对代码进行必要的优化重构提取。
现象分析：正常情况下，代码出现以上问题，是不能够上线的。但是项目中存在这些情况，肯定是缺少了一些关键的检查环节。
基本情况了解后，找了同事了解情况，询问了他们日常需求开发和编码的过程。发现他们大都是一个完整的功能开发，简单测试（关注点）没有问题，代码直接提上SVN。然后找到测试组，告知可以测试了。
测试组得到通知后，对照测试用例，进行流程测试。发现问题后，找开发人员复现问题，并要求修改后再进行测试（一般会有多次反复修改），这里有一个问题是
测试如果发现问题，开发修改后，测试会着重对这个问题的修复情况进行测试，在多次重复修复的过程后。之前的问题可能会出现，但是测试后期由于着重点放到了已经修复的问题上
导致对整体流程的测试放宽。（代码修改，特别是不熟悉的代码修改，可能影响到其他的功能模块，这一点是测试很难发现的）
综合以上的问题提出以下改进点：
1，在开发完成一个完整的功能后，增加一个review的步骤，主要由组长完成。组长对本组的代码质量负责。（项目组已经有基本的代码规范，没有的话需要先制定规范）
2，在开发一个复杂功能的时候，需要给出详细的解决方案，必要时需要使用工具比如visio画出关键思路（有些开发人员总想着加快开发的进度，对这一步要求不高，甚至认为这个是耽误时间。不加思考就开始编码。这是不对的）
3，针对测试，要求在所有功能开发完成后，上线前，对所有相关的功能进行一个全量的测试（这个工作量较大，具体情况要看项目组中测试组的人力是否满足要求，需要做适当调整）
题外话：本项目的主要开发人员工作经验大都只有一两年，编码经验和工作经验稍有欠缺。代码规范这部分需要持续的监督。促使养成较好的编码习惯。