一个关于移动的项目，现在做了快两年了，项目越来越大，其中有的表数据加上历史数据都到10亿级别，由于这两年团队成员流动大，导致代码越来臃肿，前期项目代码的管理不善，除了较大的版本，一般的小修小改都不经过代码评审，本地测试通过后，直接hotfix，有时候很顺利，但是偶尔导致较大问题，有时候甚至影响客户使用，导致公司亏损。现在领导发现问题直接骂工程部，导致现在每当有一点点修改，工程部都要求AQ按照测试用进行全用例测试，测试非常的不易，光是功能测试几乎5个测试人员时间，还要兼容几乎所有浏览器（ie6~8，火狐，遨游，TT，360，google，搜狗）。工作量巨大。没办法现在我们的做法如下：

　　1、加强代码的版本控制，对每次代码的修改，都直接联系到个人，代码的修改都要写修改说明，包括：修改内容，修改前效果，修改后效果，对其他接口或功能的影响，回滚策略，测试用例。

　　2、代码评审：代码评审的标准我们也在不断修改完善，过一段时都会对评审标准进行评审。评审前参会人员都会拿到上一步相关人员写的修改说明，会前2小时阅读，会中，有相关人员对代码进行流程讲解，并进行效果演示，评审内容包括，代码评审（是否符合代码评审标准），效果评审（是否达到产品需求效果），用例评审（是否可以覆盖当前修改），回滚评审（出错后是否可以及时的回滚到前一版本）。

　　3、总结每期评审结果，必要时间进行讨论，提出问题：包括项目中遇到的难题，和大家对评审的看法，总结经验，并对公认的技术问题进行归类，由对此熟悉的人员（架构师，开发经理，个人）在周一进行技术讲解（我们是每月2次的技术培训，没有公共话题的情况下，如果有人想分享个人经验的话，可提前准备，现在为了鼓励大家，根据培训效果，对培训讲解人是有偿的，奖励多少不公开，会中很活跃，一般不会刻意打断你，除非公共话题，这一点我是比较喜欢，每天都会去翻大量的文章，书籍去了解话题）。

　　4、和绩效挂钩，这一点大家都不喜欢啊，不过没办法，领导意思，每次上线都搞得心里惶惶的。

　　这些工作我们做了半年，也是有成效，有时候评审会叫上工程部的人来看，工程部也承认我们的工作，也不怎么要求全用例了，但是好多都慢慢形式化，包括评审，主要还是有时候项目特别紧，大家都加班加点干项目，为了上线，项目都改了好几个版本，还没评审一次，结果可想而知。有时候也想过自动化测试，但是离开了人为的控制任然问题多多啊，主要是自动化测试这方便经验不足。

　　不知道大家在开发大型项目的过程中，都是如何保证产品质量的，主要是如何在项目比较将紧的情况下防止全用例测试，不要说你们每次修改都全用例测试，都是绿灯才上线，全用例测试对我们来说那简直是要命啦，也不要说刚招聘的一个新人他写的代码你放心不用测试评审。

　　我个人认为是可以避免少量修改导致的全用例测试的，主要的问题是修改带出来的新问题，如何防止修改老问题带出新问题，个人认为有以下因素导致：人的积极性，人的责任心，人的上进心。人的积极性需要领导层共同解决，如何在紧张的项目下给员工舒适的环境和心情，人的责任心和上进心是是自己的素养，不管多么没意思的工作你是否愿意去做好，还有是你是否愿意提高你的技能来防止这些问题。但是这每一点都不是嘴上说说能做好的。