“云、架构即代码、具有API和反脆弱系统的联邦架构，这些软件系统开发技术正迅速成为关注焦点”。这是Mary Poppendieck在GOTO Berlin 2016大会上做“软件工程技术的未来”演讲时所提出的。

当数据量大到无法被单机所管理时，有两个解决方案，即纵向扩展和横向扩展。纵向扩展通过扩容单机的能力实现，Poppendieck指出通常这并非是解决问题的正确方向。很多情况下需要做横向扩展，通过添加更多的计算机构建集群系统。

Poppendieck在演讲中给出了两种不同的横向扩展方法：

• 文件的横向扩展。以Google的搜索技术为例，文件被分割为多个小块并分别拷贝到多个服务器中。这样搜索可并行地完成，并通过合并各个服务器所给出的结果得到最终的搜索结果。

• 架构的横向扩展。以Amazon的做法为例，事务会被切分为多个服务，每个服务使用特定服务器实现。当事务存在瓶颈时，可在多个服务器上复制服务，并且每个服务由一个半自治的“双比萨”团队（译者注：“双批萨”原则指团队规模不应超过两个披萨饼还不够吃的人数）负责。

Poppendieck提到，越来越多的系统正在向云上迁移，云就是未来。她指明：

相比于大多数预制的数据中心，云更便宜、更稳定、更安全并且更具扩展性。

将已有的应用转化为基于云的应用是十分具有挑战性的。Poppendieck引用了IBM的Arthur Cole所说的话：

针对传统数据架构所设计的应用如果不做大量的代码重构工作，就无法在云中很好地运行。

Poppendieckz在演讲中给出了几个已有的架构即代码解决方案：

• 使用容器，实现了过程的标准化和自动化。

• 无服务器架构，以更低的价格提供了灵活的计算容量。

• 软件定义网络，使用软件而非硬件实现了规模扩展。

单一的中央数据库会产生依赖性问题，这是由于所有的应用都依赖于数据，数据库的改变将会影响到很多的应用。Poppendieck指出：“企业数据库是一个巨大的依赖性生成器”。由于每个独立团队的工作必须要和其它共享同一数据库的团队协作，这导致每个团队都无法实现自治的部署。联邦架构是单一数据库的替代技术，它将数据分割为适合各个独立模块或服务需求的本地数据存储，数据的存取只能通过API方法。API正在替代中央共享数据库，并使物联网成为可能。Poppendieck指出，使用API是软件工程的必备技术。API应作为有具体团队负责的产品看待，并通过聚焦于API用户来推进和开发新的功能。

Poppendieck说，没有必要尽力去实现系统零故障，我们可以换一种思维。当前很多的系统都是脆弱的，虽然它们在刚上线时都是鲁棒的，但是随着时间的进展，它们变得越发地难以维护。Poppendieck提出，当今系统需要的是反脆弱，并具有面对故障的能力。在发生故障时，系统应能限定损害的程度，并从故障中恢复。

如何获取反脆弱系统取决于系统测试的方法，即如何通过注入故障产生给定的运行错误。Poppendieck指出，为达到所期望的可用性和鲁棒性等级，系统需要隔离故障并从故障自动恢复。

Poppendieck提到了当前开发软件的关键事宜，她说，为具备持续集成的能力，需要一个部署流水线；为获得持续集成所承诺的优点，需要具有一个包括产品管理、测试和运营的跨功能团队。部署流水线依赖于自动的测试、迁移和部署过程。持续集成需要所有团队通过代码库做交流，实现针对主干分支的持续集成。团队应维持软件时常处于发布就绪的状态，如果事实并非如此，你必须停下来并做到上述要求。只要实现了持续的部署，一旦有用的软件增量或功能就绪，就可通过切换或转换实现软件的增量发布。

Poppendieck提出，持续交付提供了必要的端到端反馈。研究显示在半数情况下产品经理是错的，产品规格说明中会有三分之二的特性和功能是没有必要的。导致这些问题产生的原因在于做实验验证某个特性是否可以真正地解决手头问题之前，就试图达成具体开发特性的细节。为确保开发的解决方案能很好地适用于所需解决问题，需要通过实际的使用产生快速的反馈，这也正是精益开发和敏捷开发实践的真正价值所在。Poppendieck建议将发布团队转变为在一定条件下可解决问题的团队。

Poppendieck建议在系统开发的过程中采用基本的工程性过程实践、在现实制约因素的范围内学习，并且建议从模式或者信号而非需求或是特性开始。然后聚焦于问题本身并使用假设去规划工作。基于上述方法，开展多个实验并使用实验结果数据决定应如何继续工作。

原文地址：http://www.infoq.com/cn/news/2016/12/future-software-engineering

        
.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注