如果没有代码审查的话，

　　可能会隐藏某些潜在的问题（比如，某人改动了一个基础的方法，没有考虑到该方法在其他地方也用到。其他同事在审查代码的时候也许就能帮助发现问题）；

　　新写的代码与系统最初的设计思路不吻合；

　　重新发明轮子，同样的工具方法，每个人都实现了一遍，到最后谁也不知道该用哪个。

　　这些问题在后期是很难修复的，特别是涉及到系统设计的问题，开发人员会说，“已经通过QA的测试了，再修改的话，他们还得测试呢”，最后也就只好那样了。新加入的开发人员由于不知道一些历史原因，修改代码的时候参考现有代码，经过几个版本后，代码的设计和最初的思路完全不一样，然后大家就会抱怨系统设计得太烂了，之前的代码写得太烂了。

　　虽然代码审查的反馈成本高，但是没有代码审查的影响也很大。因此，在各大软件公司和开源项目中一直都是必须的，

　　3、产品运营数据分析

　　产品好不容易上线后，用户有没有使用新加入的功能，用得爽不爽，花了多少时间完成一个典型的任务。这些问题是产品经理们非常关心的，它们关系着产品是否达成预定目标以及未来产品改进的方向。不只是产品经理，开发人员也常抱怨自己不知道自己做的功能用户的反馈怎么样，如果能够得到用户正面的反馈对开发人员是极大的鼓舞。

　　收集产品运营的数据能够给产品经理提供这些方面的反馈。在这个反馈中，收集用户使用产品的数据的成本是非常高，需要在软件里面加入相应的功能模块，并且想办法把数据从客户那里传回来（这里针对的是客户端软件），最后还得有程序来分析数据。但假如没有来自用户使用行为的反馈，做产品就是盲人骑瞎马，加了一堆用户根本不用的功能，而对用户的痛点却一概不知。因此，现在很多软件里面都会收集用户使用行为，有的会告诉你搜集了哪些信息，有的流氓一点就悄悄地搜集了。

　　这个反馈的时间很长，必须要等到产品做出来之后，并且用户使用一段时间后才能得到反馈，这就需要利用原型测试来得到用户早期的反馈。

　　反馈与软件开发实践

　　1、持续集成

　　持续集成的基本思想是每当有人签入代码的时候，都会触发一次系统的构建（Build），并且运行所有的单元测试。如果有问题，立刻通知最后一次签入代码的开发人员。在没有持续集成的时候，系统的构建通常是在夜深人静的时候启动，每天就构建一次。

　　每天构建一次的问题是什么？如果一天有很多人提交代码，并且当天的构建失败了，或者有单元测试失败了，大家只有在第二天来的时候才知道，这将影响到等待需要用当天构建做测试的同事。同时，因为有很多人签入了代码，谁都有可能是导致构建失败的人。如果有持续集成，构建一旦失败，肯定是最后签入代码的那个人的代码造成的，问题的原因很快就能找到。

　　持续集成将新签入代码对系统的影响的反馈时间从一天下降到一次系统构建的时间。持续集成的成本很低，一旦配置起来，无需开发人员的参与，一切都是机器自动完成的。因此，现在持续集成是个非常热门的话题的。

　　2、敏捷开发

　　传统的瀑布开发流程是全部开发好了再交给客户。而敏捷开发的思想之一是在每个迭代结束都向客户交付可以运行的软件并听取客户的意见。显而易见，客户反馈的时间明显减少，客户的需求也能在下一个迭代中得到解决。

　　3、结对编程

　　结对编程可以解决代码审查反馈时间过长的问题。当你在写代码的时候，你的伙伴就扮演了代码审查者的角色，并持续地给你反馈。但是其成本较高，没有被大规模地采用。

　　总结

　　软件开发流程和实践非常多，在决定是否增加一个步骤到流程中或者是否采用某种开发实践的时候，看看它是否在流程中增加了反馈，并利用反馈的基本原来来分析一下，它带来了什么，成本是什么，没有它又会怎么样，有没有替代的办法来平衡反馈时间和成本，这样才能调整出适合自己团队的流程。