1、代码审查，先把稳定性审查、性能审查、集成审查先夯实。连代码BUG、代码性能都审查不出来，何奢求其他？所以代码实现符合功能设计、代码规范性、代码解耦等等先放放。
2、如何审查代码是否有稳定性的BUG漏洞？你凭经验你肯定想不出来。所以要爬下身子耐下性子，一条条的分析咱们现有版本生产中遇到的BUG，一条条分析如何在代码审查阶段就找到，或者干脆在代码骨架设计期就保证不会出现，而不要造成还是让测试人员在后期找到了。我们开发人员自己都不保证代码质量，而想让测试人员保证代码质量，这是大大的错误。开发部门的每个人都要警醒。
3、代码审查最好是工具审查。工具既是手段也是目的。逼迫你做成工具，其实是逼迫你把问题想的能落地，这就是手段。另外，如果能做成工具，那么换谁来做都能保证质量。而不是只有高手才能做。毕竟高手太少，而有限的高手被忙的团团转根本没有那么多时间，这就是目的。
解决方法不能出现：不能出现加强自测、加强详细设计、加强评审这类的话。
要一类BUG有一条明确的对应方法。如有人在代码中写死http,然后有客户要使用https，咱们的代码就会报错。针对这个BUG，我们就要做个工具来做代码审查，看看还有没有人在代码中写死http这样的字样。
4、先集中火力解决最大的三类BUG，而不要挑什么BUG有解决方法就先解决哪个。我们不要避重就轻，不要专拣软柿子捏。那没有明显效果。要做，就直捣黄龙。捣彻底。我审查了3个版本4个子系统的BUG统计，BUG前三类是：功能错误、界面缺陷、数据错误。而前三类却占了所有BUG数量的50%还多。大家先圈定在这一个范围，集中火力。不用把所有BUG都分析了，那没有时间。
也有人提到这三类里面的BUG不少是设计遗漏造成的。这类问题我们要再深思，对于这类BUG我们真的没有办法吗？不要一杆子推到设计人员身上自己就不思考了。我们要思考思考，我们在代码开发阶段如何也能做点事。
当然，我们设计部门也在优化方法论来力求设计面向业务场景，测试人员是拿设计文档而非需求文档来进行测试。我们也这次强调了，测试人员是要测试代码实现是否符合功能设计，而不是测试设计是否符合需求。设计是否符合设计，我们已经分职责让产品经理来校验设计文档是否符合需求。
我们目前在测试阶段出现设计不符合需求这类BUG报告是很奇怪的一件事情。随着我们测试部门不断加入新人，他们不了解咱们的地产业务，也没有见过客户，也没有真实到过客户现场，他们怎么就能测试出来设计不符合需求。这也太奇怪了。而且，咱们应该是一环环相扣，产品经理作为需求提出方，肯定要检验设计是否符合需求。而测试，是为了测试代码是否满足设计。测试也应该开展两方面测试，一方面是黑盒测试，通过模拟真实客户操作业务场景来测试代码是否符合设计，一方面是白盒测试，通过内部代码机理、数据变更变化来测试代码是否符合设计。
就是因为咱们设计目前没有以业务场景为中心，所以产品经理不容易通过功能来检验设计是否符合需求。所以测试也无法拿设计文档来模拟客户业务场景，所以只好拿需求文档来编写自己的测试文档，又重新发明轮子，还未必和设计人员的业务场景一致。这是咱们过去遗留问题，我们未来不希望这么走。
5、代码审查的终极目标追求就是取消代码审查，而不是把代码审查越做越好。大家一定要认清楚这个终极追求，不要把手段当了目的。我们力求在代码骨架设计和底层设计和平台解决问题，实在解决不了，才在代码编写后做代码审查来擦屁股。所以我们不要把目光就局限在如何把代码审查做到位查到更多的问题，而是我们要力求把代码问题在前期在底层就保证了根本不会产生这样那样的BUG。
况且，我们的BUG一点的不新鲜。逐一看看我们的BUG清单吧，每个BUG都似曾相识，我们已经历年历次犯了。所以这么多似曾相识的BUG，我们的解决方法也应该是有一定套路的。