有开发者写了某个功能的代码，想知道这个功能是否已经实现，是否需要改代码。这是一种反馈。在软件开发中，特别是联调时，缩短反馈弧有助于及时发现问题，采取对策，提高开发效率。那么什么样的反馈弧被认为是短的呢？您如何看待缩短反馈电弧的投入产出比？本文分享了阿里巴巴研究员南门对软件开发反馈弧的思考和看法。1为什么缩短反馈弧是关键俗话说“没有测量就没有改进”。但句子并不完整。测量对改进的作用是反馈，但仅仅测量是不够的，必须足够频繁、足够快地进行测量，这样才能更有效地进行改进。有许多现实生活中的例子可以说明缩短反馈回路的价值：减肥。如果你每天称体重，它会帮助你减肥和控制体重。如果你吃得太多，看着自己的体重一天天上升，你就会觉得心里有压力，就会控制住。如果不每天称体重，很容易放纵自己，一发不可收拾。每天称体重和每六个月称一次体重对减（gai）脂（jin）的效果是完全不同的。吃饭，如果吃得太快，很容易吃多。原因也是反馈弧太长了。人的饱腹感是有延迟的，从肚子饱到大脑感觉饱是有延迟的。在这段时间里，如果你继续吃东西，你会吃得太多。育儿是反馈弧的另一个很好的例子。家里有孩子的人都为育儿焦虑。因为：不知道自己现在做的事情会对孩子以后的上学和就业有什么影响。在育儿方面，反馈弧的长度取决于年份。工作中也有很多例子：在线变更，我们强调“可监控”。做出改变后，如果能第一时间得到高质量的反馈（高质量的反馈=高监控覆盖率、低噪音、合理的阈值设置），对判断我做的改变好不好是很有帮助的。资金损失验证，从T+1，到T+H，再到TM，也是一个不断缩短反馈弧的过程。反馈弧的缩短对于及时发现问题，及时采取对策很有帮助。系统设计分析的评估遗漏仍然是反馈问题。我的部门分数，对吧？有什么遗漏吗？在部门的时候，我做了一个判断：这个链接是可以复用的。那么这个判断正确吗？有没有遗漏，判断是否正确？这些都是反馈。我们通常说的“商业试错”，也是一种反馈。“试错”的意思是：试一试，看对不对，错了就回头，对了就继续投资。“快试错”就是要缩短业务效果的反馈弧度。没有“快速试错”的能力，就是反馈弧长，不好。我们必须有快速试错的能力。晋升也很痛苦。因为推广的反馈弧也很长。努力了两三年，还要准备升职报告，不知道评审团最后会怎么评价。为了解决这个问题，如果可以在过程中加入一些非正式的汇报来提供反馈，那将是非常有效的。二、如何计算反馈弧长？反馈弧长不短，有两个方面：反馈的前置时间等待时间。理想状态是：无需等待反馈，随时反馈。反馈本身很耗时。理想的状态是：反馈本身的耗时很短，马上就有结果。比如20、30年前，你得去医院测血压（测血压是一种反馈），你得等到医院早上开门，挂个号，排队等等，轮到你的时候医生会给你信息。量一下血压。因此，没有必要随时测量血压，测量血压前的等待时间很长。但是测量血压本身需要很短的时间，一分钟就知道结果。以后有了家用血压计，测血压就不用等了，也不用求助于医生。您可以在家中随时测量血压，每天早中晚三次，甚至每小时测量一次。有了家用血压计，虽然血压测量本身耗时的反馈动作并没有缩短很多，但频率却增加了。随时反馈，前置等待时间缩短为几乎为零。这种变化极大地帮助患者控制血压。同样，血糖的控制也大同小异。过去，你必须去医院验血才能知道你的血糖。现在有一些新技术可以让患者自行测量血糖，只需捏指尖即可。这种变化将极大地帮助您控制血糖。软件开发活动中的反馈是类似的。我是开发人员，改了一行代码，想知道这行代码有没有问题。这就是给我反馈。我是开发人员，写了大半天的代码，写了某个功能需要的代码。现在我想知道这个功能是否可以工作以及我的代码是否应该更改。这也是反馈。今天，在一些团队中，如果开发人员想要获得这些反馈，反馈弧线仍然很长。长在两个方面：1）你要等，不能随时要反馈。2）反馈本身是费时费钱的，而且结果不是立竿见影的。反馈弧越长，开发效率越低。在一些团队中，反馈弧的长短体现在他们的开发联调上：反馈不是随时随地都有的，你要等。因为不可能随时随地发起交易。不是每个人都知道如何发起求和，只有某些学生知道如何发起求和。反馈不是即时的。即使发起交易，也需要在每个域中找一个同学查资料。同时，反馈的质量不高，反馈不一致，因为检查是人做的，不同的人做的检查是不一样的。持续集成就是缩短反馈弧。我们一直在做各种事情，比如更改代码、向数据库添加字段、修改DRM值以及向数据库中插入数据。持续集成就是在每件事做完，每一个动作发生后第一时间给我反馈，告诉我各种场景是否工作，代码是否工作。“持续”，随时随地反馈。自动化是缩短反馈弧的必要条件（但不是充分必要条件，因为自动化之后还有覆盖面、充分性、有效性等要素）。如果还是人工步骤，不可能做到很短的反馈弧度，因为不可能随时随地都有人，人的动作也很慢。3、缩短反馈弧的成本和投入产出比缩短反馈弧，构建持续集成，确实需要投入成本。编写自动化、维护整个基础设施、维护持续集成的良好运行都需要人和时间。但为缩短反馈弧而投入的成本可以从别处收回。很多人只看到了构建持续集成所需要的投入，却没有去计算另一笔账：如果这个做得好，可以节省多少时间。例如，对于每个项目，每个联合（ji）调试（cheng）用例和检查都是自动化的，这种初始投资将在项目进展过程中得到回报。例如，每一次人肉检查可能需要长达15分钟的时间来进行人体检查，包括寻找人的努力。要使此检查自动化需要2小时的工作（包括自动化和后续维护）。那么，如果整个项目期间要做的检查次数超过8次，这个自动化就很划算了。事实上，一个检查在一个项目中运行超过8次。现在，一个check在一个项目中可能只跑几次，但这是因为实在没办法跑多了，因为每次check都很累。但是如果它是自动化的，check可以运行很多次。我们希望检查将运行多次。因为：我们希望在修改代码的时候能够随时随地得到反馈。另外，随时随地跑检查，随时随地得到反馈还有一个很大的好处，那就是可以让排查问题变得非常方便。在1990年代，IDE并不像今天这样好。例如，在使用TurboC2.0编写代码时，许多程序员习惯于每隔几分钟编译一次代码。因为那时候的IDE比较“简单”，不像今天的IDE，如果某处有错别字，比如变量名或者关键字，马上会有波浪线提示。当时的IDE没有这样的提示。如果你写半个小时或者一个小时的代码，写几百行，然后编译，如果编译有问题，排查起来会比较困难（虽然编译错误会告诉我是哪一行错误，但问题的真正根源可能不在报告错误的行上）。所以当时大家都是每隔几分钟就编译一次代码，一旦出错，就知道问题出在几分钟前刚刚写的代码上。这就是缩短反馈弧使故障排除更容易的原因。不能孤立地看待构建持续集成所投入的成本。如果我只站在一个开发者的角度来看，我的投入产出比可能不会很高。可能在某些情况下，我用原来的方法更方便。但在很多时候，个体的利益往往会导致群体的损失，进而导致个体的损失。个人做出一些小的贡献，这将造福于整个群体，进而造福于每个个体。生活中有很多这样的例子。如果大家开车不按顺序，乱变道、乱塞车，就会造成整体道路秩序混乱，导致整条高速公路的车速变慢，进而导致大家晚点回家。疫情防控也是如此。一些当地的隔离措施是对个人的一种支付。然而，这些个人的努力反过来也使团队受益。我们全社会的疫情防控工作做好了，全社会的经济都恢复了，又让每一个人受益。
