我在大学里面学的专业是自动控制。反馈是任何自动化控制系统中必不可少的。比如，在控制锅炉炉温的控制系统中，想要把炉温控制在600℃，那么传感器必须周期性采集锅炉的温度，控制系统再根据炉温来调整火力。温度不够的话，烧火的还得再给点力；温度差不多了就可以一边歇着了。

　　反馈的概念相当简单，它在很多地方都发挥着重要的作用。本文抛砖引玉，初探软件开发流程和实践中的反馈以及利用反馈来改进流程的一些想法，并利用反馈的原理来分析现有的开发流程和最佳实践。

　　软件开发中的反馈

　　大型软件的开发是分布在世界各地的开发人员的数个月的体力和脑力劳动。各大公司都有一套开发流程来保证产品能够按期交付。如果仔细分析这些流程以及流行的最佳开发实践（Best Practice），它们无不是利用了反馈的基本原理。

　　在软件开发中，我们应特别关注反馈的以下两个因素：

　　反馈的成本（Cost）：成本主要是指要花多少开发或者测试人员的时间来获得反馈。

　　反馈的价值（Value）：如果没有这些反馈信息，会产生什么影响，以及在以后需要多大的成本来修复，这也就是反馈的价值。

　　仔细分析流程中反馈的这两个因素，可以找到流程改进的方向：

　　关注流程中成本过高和反馈时间太长的反馈，想办法使得某些反馈能够自动化。尽量减少人工的参与，因为人的成本是很高的。

　　去掉或者优化流程中那些成本大于价值的反馈。反馈的引入是为了及早发现问题，因为通常问题早发现的修复成本更低。但是如果问题不严重，而且修复的成本也很低，为什么要在前期花更多的时间来避免这样的问题呢？

　　开发流程的反馈

　　1、原型测试

　　在项目正式开发之前，产品经理通常会和交互设计师一起设计系统的原型，然后邀请一些用户来做测试。

　　原型测试将用户对产品的想法，比如用户是否对产品有需求，用户是否愿意掏钱买等信息反馈给了产品经理，使得产品经理能做出相应的决策，比如如何去调整产品的方向，是否继续在这个产品上投入。在这个反馈中，反馈的成本远小于反馈的价值。如果方向错了，后期开发和测试的时间都是白费了，所以原型测试被广泛地采用。最没效率的事情是在错误方向上努力做事。

　　我所在的公司，开发人员在开发与界面相关的功能时，也是首先用mockup工具或者画图板把界面先画出来，找到相关的专家审核，通过审核后再开始写代码。虽然看起来正式写代码的时间比较晚，但是能避免后期返工，所以总的时间比一上来就写代码花的时间要少。

　　2、开发过程中的反馈

　　2.1 集成开发环境（IDE）中的反馈

　　用过Eclipse的程序员都知道，假如写错了一个关键字或者方法的名字，Eclipse会立刻高亮显示错误的关键字，这样程序员就可以立刻修改错误。IDE将语法和编译错误及时地反馈给了开发人员。在这个反馈中，反馈几乎是实时而且几乎没有成本的，极大提高了生产效率，所以在实际的开发中没有不用IDE的。

　　2.2 单元测试

　　单元测试是对一个类或者方法进行的测试，它保证你写的类或者方法是按照你的想法工作的。

　　单元测试将一个类或方法中的错误反馈给了开发人员，使得开发人员能及时修复错误。单元测试中发现的问题通常很快就能修复因为测试的范围仅限于一个类或者方法。在这个反馈中，写个测试案例可能只要几分钟，但是如果不进行单元测试而是直接就把整个系统跑起来测试，很有可能你的一个拼写错误（比如把！=写成了==）要花上1个小时才能发现，或者你没有考虑的边界情况在客户现场导致很诡异的问题，要花上几天才能找到原因并且给客户不好的印象。仅仅从这个角度来讲，单元测试也是很有必要的。想要做好单元测试，需要良好的环境支持，参见这里。

　　2.3 代码审查

　　医生通常不会一个做手术，那么同样程序员也不能一个人写好代码就提交了。因为是人就会犯错误，代码审查是让其他同事帮助发现代码的问题。

　　代码审查者将代码中如下问题反馈给开发人员，比如代码风格是否统一，新写的代码是否符合系统的设计思路，是否重新发明轮子等等。

　　真要做好代码审查，成本还是蛮高的。首先，为了让别人能看理解你的代码，特别是代码比较多的时候，要组织大家来介绍一下背景，然后被邀请的同事再去阅读代码并提出修改意见。其次，争议比较大的时候，还要组织会议来讨论这些修改意见。可以看到，代码审查不是占有一个人的时间，而是几个人的时间。所以，从提交代码审查到拿到审查意见的反馈周期还是有点长，一般需要1-2天的时间。

　　为了使得代码审查的反馈更加及时，我所在的团队采用的方法是，在做大的改动之前，先把修改思路和设计方案与审查者沟通一下（解决方案的审核），及时发现与当前系统设计不一致的问题，然后才开始编码，从而避免代码已经写好了，审查者对系统设计提出大量的意见。