开发者写好了某个功能的代码，想知道这个功能是不是实现了，代码还需不需要再改，这就是一种反馈。在软件开发中，尤其是联调时，缩短反馈弧有助于及时发现问题、采取对策，提高开发效率。那么什么样的反馈弧才算短?如何看待缩短反馈弧的投入产出比?本文分享阿里巴巴研究员南门对软件开发中反馈弧的相关思考和看法。
一 为什么缩短反馈弧是关键
都说“没有度量就没改进”。但这句话还不完整。度量对于改进的作用是给反馈，但单单有度量还不够，还要度量得足够频繁、度量得足够快，这样才能更有效的进行改进。缩短反馈弧(feedback loop)的价值在生活中有很多例子：
- 减肥。如果每天称体重，就有助于减肥、有助于控制体重。吃多了，看着体重一天天上去，心里就有压力了，就会控制。如果不是每天称体重，就容易放纵自己，一发而不可收拾。每天称体重，和每半年称一次体重，对减(gai)肥(jin)的作用是完全不一样的。
- 吃饭，如果吃太快，就容易吃太多。原因也是反馈弧太长。人的饱腹感是有delay的，从肚子已经吃饱了，到大脑感受到饱腹感，有一个delay。在这个delay这段时间里，如果继续吃，就会吃多了。
- 育儿，是反馈弧的另一个很好的例子。家里有小孩的人，都对育儿很焦虑。因为：不知道现在做的这些事情，对小孩将来的上学、就业会产生什么影响。在育儿这件事情上面，反馈弧的长度是论年记的。
工作中也有很多例子：
- 线上变更，我们强调“可监控”。做了一个变更，如果能马上得到高质量的反馈(高质量的反馈 = 监控覆盖率高、噪音低、阈值设定合理)，就非常有助于判断我做的这个变更是好的还是不好的。资损核对，从T+1，到T+H，到TM，也是反馈弧不断缩短的过程。反馈弧缩短是非常有助于及时发现问题、及时采取对策的。
- 系统设计分析的评估遗漏，仍然是反馈的问题。我的这个系分，对不对，有没有遗漏。我系分的时候做了一个判断：这个链路可以复用。那么这个判断对不对?有没有遗漏、判断对不对，这些都是反馈。
- 我们平时说 “业务试错”，也是反馈。“试错”的意思就是：试一下，看看错不错，如果错了就掉头，如果对了就可以继续投入。“快速试错”就是业务效果的反馈弧要缩短。没有“快速试错”能力，就是反馈弧长，就不好。我们要有快速试错能力。
- 晋升，也是很痛苦。因为晋升的反馈弧也很长。辛辛苦苦干两三年，还要准备晋升述职，也不知道最后评委会怎么评价。为了解决这个问题，如果能在过程中增加了一些非正式的述职，提供反馈，效果就很好。
二 怎么算反馈弧短?
反馈弧短不短，有两个方面：
反馈的前置等待时间。理想状态是：反馈不需要等，任何时候想要反馈都可以。
反馈本身的耗时。理想状态是：反馈本身的耗时很短，结果立等可取。
打个比方，二三十年前，那时候量血压(量血压就是一种反馈)是要去医院量的，只有等早上医院开门了、挂个号、排队等，轮到你了医生给你量血压。所以不是任何时候想量血压就能量血压的，量血压的前置等待时间很长。但量血压这个事情本身，耗时很短，一分钟就知道结果了。后来，有了家用血压计，量血压就不用等了，也不需要求助于医生，自己在家里任何时候都可以量，可以每天早中晚量三次，甚至可以每小时都量一下。有了家用血压计，虽然量血压这个反馈动作本身的耗时并没有缩短很多，但提高了频次，任何时候想要反馈就可以给反馈，前置等待时间缩短到几乎为零。这个变化就大大的有助于病人控制自己的血压。类似的，控制血糖也是类似的道理。以前要知道血糖是要去医院验血的，现在有一些新技术，可以让病人自己就可以测量血糖，手指尖夹一下就可以了。这个变化就大大的有助于控制自己的血糖。
软件开发活动中的反馈也是类似的。我是一个开发，我改了一行代码，我想知道这行代码有没有问题。这就是给我反馈。我是一个开发，我写了大半天代码，把某个功能需要的代码写好了，我现在想知道这个功能是不是能work了、我的代码还要不要再改。这也是反馈。今天，在有些团队，一个开发要得到这些反馈，反馈弧还很长，长在两个方面：1)要等，不是任何时候想要反馈都可以。2)反馈本身的耗时长、成本高，结果也不是立等可取的。反馈弧一长，开发效率就降低了。在一些团队里，反馈弧长，在他们的开发联调中的体现就是：
- 反馈不是随时随地的，要等。因为不是随时随地都可以发起一笔的。也不是每个人都知道怎么发起一笔的，只有特定的同学才知道怎么发起一笔。
- 反馈不是立等可取的。就算发起了一笔交易，还要找一个个域的同学check数据。同时，反馈的质量也不高，反馈不consistent，因为check是人做的，不同人的做的check不一样。
持续集成就是要缩短反馈弧。我们平时一直在做各种事情，比如改代码、数据库加字段、修改DRM值、数据库里插入数据。持续集成就是每件事情做了以后、每个动作发生以后，都要尽可能快的给我反馈，告诉我各种场景是不是通的、代码是不是work。“持续”了，反馈要随时随地都可以给。自动化是缩短反馈弧的必要条件(但不是充要条件，因为自动化了以后，还有覆盖率、充分性、有效性等要素)。如果还有人工步骤，就不肯能做到反馈弧很短，因为人是不可能随时随地都available的，人的动作也是很慢的。
三 缩短反馈弧的成本和投入产出比
要缩短反馈弧、建设持续集成，的确是需要投入成本的。要花人花时间去写自动化、去维护整个基建、去维护持续集成的良好运行。但是，在缩短反馈弧上投入的成本，是能从其他地方收回来的。很多人只看到了建设持续集成需要的投入，但是他们没有算另一笔账：这个做好了，能节省多少时间。
例如，对每个项目来说，把每个联(ji)调(cheng)用例和check都自动化了，这个前期投入，在项目进行的过程中会收到回报。比如，人肉做一次check，算上找人的功夫，加起来每次人肉check可能要15分钟。而把这个check自动化，需要2小时的工作量(包括自动化、以及后面的维护)。那么，如果整个项目过程中要做的check次数超过8次，这个自动化就是一笔划算的买卖。事实上，一个check在一个项目里面何止跑8次。现在，可能一个check在一个项目里面只跑几次，但这是因为实在没法再多跑了，因为每次check都非常累。但如果自动化了，check就可以跑很多次很多次。我们是希望check跑很多次很多次的。因为：我们希望我们任何时候改了代码，都能随时随地的得到反馈。
另外，随时随地跑一下check、随时随地的得到反馈，还有一个很大的好处，就是：能使得排查问题变得很方便。九十年代的时候，IDE还没有今天这么好，比如那时候在Turbo C 2.0里面写代码，当时很多程序员的习惯是每写几分钟代码就编译一下。因为当时的IDE比较“简陋”，不像今天的IDE，哪个地方如果有typo，比如变量名打错了、关键字打错了，都会马上有波浪线提示。当时的IDE是没有这种提示的。如果写了半个小时、一个小时的代码，写了几百行，然后再编译，如果编译有问题，排查起来就比较辛苦(虽然编译错误会告诉我哪行错了，但是真正的问题根源未必就在报错的那一行)。所以，当时大家每写几分钟代码就编译一下，一旦有错就知道了，问题就出在刚才那几分钟写的代码里面。这就是为什么缩短反馈弧能让排查问题变得更方便。
投入在建设持续集成上的成本，不能孤立的看。如果只从单个开发同学的视角看，我的投入产出比未必很高，也许在某些情况下，用原来的方式反而对个人更方便。但在很多情况下，个体受益，往往会导致群体受损，进而导致每个个体都受损。个体做一些小的付出，会导致整个群体受益，进而让每个个体受益。
这样的例子在生活中也很多。如果每个人开车都不遵守秩序，都乱变道、乱加塞，那么整体的道路秩序就会很混乱，进而导致整个高速上面的车速都降下来，进而导致每个人都更晚回家。疫情防控也是这个道理。局部的一些隔离措施对个体来说是一个付出。但这些个体的付出，换来的是群体的受益，我们整个社会的疫情防控就做好了，整个社会的经济恢复了，进而让每个个体都受益。
