现代软件工程优化学习之反馈，打通现代软件工程的任督二脉

反馈是信息传递，它将有关行动、事件或过程的评估或纠正信息传递给原始源或控制源。

除非我们能够知道并了解我们的选择和行动的结果，否则我们无法判断我们是否正在取得进展。

这似乎很明显不值一提，但在实践中，猜测、等级制度和传统却更广泛地被大多数组织当做制定决策的权威数据。

反馈使我们能够为我们的决策建立证据来源。一旦我们有了这样的信息源，我们的决策质量必然会提高。反馈使我们将神话和现实分开。

使用有计划的、预测的方法，只要你完全理解所有变量，并且没有出现任何改变你的理解和计划的情况，这种方法就会很有效。要么你的问题非常简单，要么你能无所不知地预知未来。

在反馈式方法中，你要做的只是开始工作，并对反馈迅速做出反应。这种方法实际上更有效，结果也更稳定。

第一种方法只有一种正确的解决方案，第二种方法是动态的解决方案。

编写代码，依靠测试团队六周后的报告是不够的。采用测试驱动的方法，先编写一个测试，运行它，看到失败，失败的本质是提供反馈。这些反馈周期非常短，只需要几秒。

提文代码时，触发持续集成系统，并在其他人代码的上下文中评估我的变更。我得到新一级反馈，获得更多理解。

持续集成是一天多次将所有开发人员的工作副本合并到共享主线提放法。而分支使提交者能够隔离变更。持续集成和功能分支实际上彼此之间不兼容。一个目标是尽早暴露变更，另一个则推迟这种暴露。

持续集成的发明是为了克服合并地狱。

持续集成和持续交付意味着代码的设计过程更像是一个引导进化的过程，每一个小步骤都给我们反馈，这是一个非常有挑战性的转变。这种方法不仅意味着我们的软件始终是可发布的，还可以经常得到关于我们工作质量和适用性的细粒度反馈。

可测试的代码驱动我们的设计向降低复杂性的方向进化:模块化、关注点分离、高内聚、信息隐藏(抽象)、适当耦合。这打通了现代软件工程的任督二脉:优化学习、优化管理复杂件。

极限编程及其对测试驱动开发和持续集成的应用，将测试置于开发过程的前端和中心位置。这将反馈循环缩短到几秒，几乎可以做到即时反馈错误，消除所有种类的缺陷。这些缺陷在没有测试驱动开发的情况下会被带入生产环境。

测试推动了开发过程，及软件设计本身。这将设计推到了可测试性的方向，这也是软件质量的标志。测试驱动开发不仅评估了软件的行为，还提高了软件设计的质量。

测试驱动开发超越软件开发人员的才能和经验，创建更高质量的软件。

持续交付的思想基础之一是，我们生产的软件应该随时准备发布到生产环境中，这是一个很高的标准，需要非常高频率和高质量的反馈。

持续交付帮助构建系统的架构质量，包括可测试性和可部署性。提升可测试性和可部署性，使我们可以在更短的时间内高效地收集反馈。

我们更喜欢只需要运行几秒或几毫秒的测试，和只需要几分钟甚至几秒就能完成的部署。

将架构模块化为独立的、单独的可部署单元，是微服务架构思想背后的驱动思想之一。微服务架构方法，使团队能够彼此独立地开发、测试和部署他们的服务，同时让团队在组织上解耦，让企业能够更有效更高效地发展。

首先在我编译能力即开发环境中识别缺陷，然后在单元测试中识别缺陷，只有在这些验证成功之后，才能在其他形式的更高级别的测试中识别缺陷。这意味着我们可以以更快的速度失败，并获得较高质量、更有效的反馈。快速失败也叫左移。

我们怎么知道我们的想法、我们创建的想法是好的呢?真正的答案是，直到我们从想法的使用者那里得到反馈，我们才能知道。围绕着从创建产品的创意到向生产环境中交付价值的反馈循环形成的闭环，是持续交付的真正价值。

在我们的系统中添加遥测技术，让我们能够收集有关我们系统中哪些功能点被使用以及如何被使用的数据，可以帮助诊断问题，以及帮助我们更有效地设计下一代产品和服务，将组织从业务加 IT 的形式向数字化业务转型。

敏捷方法将团队，也就是工作中的人，带入反馈循环中，这样他们就可以观察他们的行动结果，对其进行反思，并随着时间的推移改进他们的选择，从而改善他们的情况。这种主观的、反馈驱动的方法是最基本的敏捷思想检查和适应的基础。检视和适应可以与加速中的度量指标相结合，形成主客观相结合的适应度函数。

反馈对我们的学习能力至关重要，没有快速有效的反馈，我们只能猜测。反馈的速度和质量都很重要。持续交付和持续集成思想，都是基于优化我们的开发过程来最大限度地提高我们收集反馈的质量和速度。