技术实践如何支持演进式架构和持续集成

TDD、重构、持续集成和结对编程等 XP（极限编程，eXtreme programming）技术实践支持紧急设计（emergent design），并推进了架构的不断演进。持续集成是持续交付所需的首个实践，即每日都提交到主线。编写干净、考虑周全、测试良好的模块化代码，这是开发人员的最重要技能。

在 Agile Summit 2017 希腊大会上，ThoughtWorks 北美技术负责人 Rachel Laycock 就敏捷技术实践做了一次演讲。InfoQ 将以问答，摘要和文章报道本次会议。

InfoQ 采访了 Laycock，采访内容涉及演进式架构、持续交付和技术技能等。

InfoQ：您能为我们推荐一些演进式架构的实践吗？并介绍一下您推荐的原因。

Rachel Laycock：演进式架构结构引入了一些新的原则。例如，在“最后责任时刻”（The Last Responsible Moment）做出架构决策，使用匹配功能去测试架构决策并尽早解决痛苦点。后者实际上是一种采纳自 XP 的理论。它提出对于可导致痛苦的事情，要增大做该事的频率。这通常会提高做事自动化的程度，进而消除做事的痛苦。这正是持续交付实践思想的来源。通过进行更频繁地部署，消除了设置和部署环境这一漫长等待时间所带来的痛苦。在做事的过程中，人们创建了新的工具去构建并部署环境。并且使得治理过程等存在延缓的挑战性问题也得以自动化。这样，整个部署过程平淡得就像去点击按钮，而非需要耗费整个周末纠缠于其中。所有这些都是拜痛苦所致。

尽管我们具有这些新的原则，连续交付和 XP 的实践仍然是相关的和必要的。关键在于底层的特征，包括增量构建、模块化，以及围绕业务能力和实验进行组织等。XP 技术实践（如 TDD，重构，持续集成和结对编程）对紧急设计的支持，是架构得以随时发展的关键所在。由于我们的架构决策是作为“最后责任时刻”做出的，也是该时刻所需要的，因此我们需要经过充分测试的模块化代码，这样整个团队可以了解如何改进这些代码。这是我们从 XP 的实践中获得的。对我而言，如果要使用演进式架构，那么持续交付和 XP 的实践两者是“一并”的，而不是“二选一”的。

InfoQ：在持续集成中，有哪些实践已被证明是具有价值的？

Laycock：XP 的实践支撑了持续交付。在人们开始进行持续交付时，一个着手之处就是创建持续集成的服务器和流水线。持续集成只是一种工具，一种用于实现每日向主线提交的实践。但是，我们要对提交的代码具有信心。如果代码中不存在错误，那么它们是有质量的。为此我们需要一套测试。如果我们在编写代码之后进行连续交付，或者我们处于一种遗留代码的状态，那么其中通常不存在测试，这是解决问题的根源所在。我所看到的一些实例使用了清晰易懂的方式编写代码，这些代码通常都是在 TDD 实践中编写的。

持续交付解决了最终难题（the last mile problem），它引入了新的工具，创建并存储环境和部署的配置管理。即使在支持这些工具的生态系统中，我们依然可以编写一些测试，并且也应该这样做。在通常情况下，我们可对为配置管理而编写的代码做 TDD。因此从根本上说，即使在此类情况下，底层的实践也不会发生改变。

InfoQ：对于开发人员，最重要的技术技能有哪些？

Laycock： 最重要的技能是能够编写干净，考虑周全、经过充分测试的模块化代码。真正地理解在耦合与凝聚上的挑战。之后，我们可以理解在各种语言上的一些细微差别。虽然语言会发生改变，但是这些基础技能不会发生改变。

InfoQ：开发人员应如何提高自身的技术技能？

Laycock：关键就是实践、实践、再实践。学习 TDD 是一件很难的事情，但如果我们坚持实践，我们就会在学习上做得更好，直到使 TDD 成为我们工作的一种常态。只有这样，我们才有能力在是否要对代码做 TDD 的问题上做出务实的决定。总体而言，我相信只要做事的方式正确，那么我们就应该执行重构的做法。这对于将来不创造“遗留”代码或“泥球”（Balls of Mud。译者注：指缺乏清晰结构的代码）是至关重要的。泥球将不可避免地延缓慢我们的速度。

InfoQ：为立于技术实践的潮头，开发人员应如何做？

Laycock：尽管引入了持续交付和 DevOps，核心的技术实践并没有发生太大的改变。一旦我们学习会了这些技术，就可以将它们应用于我们所追求的软件设计和架构中，例如 DDD、REST 和演进式架构。

查看英文原文： How Technical Practices Support Evolutionary Architecture and Continuous Delivery