信息技术是一个日新月异的领域，从自身的发展到学科的教程，再到应用场景的无处不在，导致每天甚至每时每刻都可能会有新的技术或者新的方法涌现出来。

“吾生也有涯，而知也无涯”，那么，对于一个工程师而言，不了解并学习持续架构会落伍么？

不学习就会落伍

在前不久QCon2022（ 由于疫情的原因延迟到今年举办）上有个分论坛主题是“工程师成长实战”，无论是宗刚老师的《三倍速成长实现职场跃迁》，还是《Maven实战》作者许晓斌的《技术领导力实战》，或是老妈农自己分享的《QCon：工程师成长的金字塔思维​》，都涉及了一个同样的主题——学习。

对一个IT从业者，尤其是一名软件工程师，对自己而言，需要不断成长才能提高自己的适应能力以及市场的竞争力，才能坦然地面对所谓的“35岁危机”；对企业而言，只有不断地成长才能持续地为企业创造价值。不断地成长，离不开学习，对于我们每个人而言，可能是终身学习。

那么如何学习呢？

在老码农自己的分享中，描述了关于学习的金字塔模型，将学习方式分为了三个方式：输入、消化和输出。尽管主动学习优于被动学习，很多的学习都是从输入开始，根源上都是从问题开始的，而阅读是学习方式中非常重要的一种方法。在计算机领域的思维范式金字塔中，历史思维是其中的一个支点，“治学先治史”，所谓治史离不开阅读。

或许，每个人都知道学习的重要性，但面对浩如烟海的知识，我们学习什么呢？

学习什么？

学习什么取决于学习的目的，不是为了学习而学习，不能把手段当目的。学习的目的是为了更好地解决问题，分析并解决问题才是价值所在，而个人的成长可能只是学习目的的一部分或者副产品。

“知人者智，知己者明”，有时候，发现问题比解决问题更困难。提出一个好问题是一件有挑战的事情，因为答案往往就在问题当中。对于我们软件工程师来说，有很多问题都会落到软件工程领域，例如软件架构。

如果把问题比喻成病痛，那么解决问题则类似于治病。在《扁鹊见蔡恒公》中有“君有疾在腠理，不治将恐深”，很多致命的问题可能都是小问题日积月累形成的。而治病的更高境界可能是“治未病”，即“防患未然”。然而，我们常见的情形往往是“曲突徙薪忘恩泽，焦头烂额为上客”。基于个人和环境的局限，我们的预见能力可能非常有限。

但是，我们可以通过学习，参考业界对未来的遇见，帮助我们提升洞察力，例如Gartner 对技术趋势的预测。2023年， Gartner 对十大战略技术趋势的预测如下：

• 数字免疫系统
• 应用可观测性
• AI信任、风险和安全管理
• 行业云平台
• 无线价值实现
• 自适应人工智能
• 可持续技术

这十大技术趋势划分为优化、开拓、扩展三大主题，其中，优化包括：数字免疫系统、应用可观测性、AI信任、风险和安全管理；开拓包括：元宇宙、超级应用、自适应AI；扩展包括：行业云平台、平台工程、无线价值实现。而可持续性技术贯穿2023年的所有战略技术趋势。那么，什么样的可持续性技术会贯穿所有的领域呢？聚焦在软件工程的话，恐怕应该是持续架构了。

从架构到持续架构

软件架构是客观存在的， 不论你是否主观情愿，它都在那里。然而，架构一词源自隐喻（关于隐喻的学习与思考​），所以对软件架构的范围，人们往往有着不同的看法。例如，宏观的系统结构，把架构认为是一个软件系统的高级抽象，由一组计算组件和描述这些组件之间交互的连接器组成；那些对系统及其涉众有重大影响的决策；作为系统和开发项目的蓝图等等。

老码农喜欢用时空观来分析问题，在《如何进入一个新领域​》以及《面向全栈的技术管理​》有过描述。一般地，对于软件架构而言，从空间视角来看是软件系统的体系架构，例如架构模式（​软件架构的10个常见模式​）等；从时间视角来看是架构决策和实现流程。实际上，软件架构是时空视角的结合与统一，也就是说，在一般意义上，软件架构是指软件系统的基本结构以及创建这种结构和系统的规程。

令人困扰的事，基于时间的单向性和动态性，与时间相关的软件流程乃至所谓的“最佳实践”有时候往往又会成为生产力的约束。老码农个人认为，持续架构以及可持续性技术都是对时间视角架构问题的积极探索和实践，并且涵盖了空间视角架构的大多数方法。

什么是持续架构呢？这需要从明确架构活动开始——

软件架构是由业务目标所驱动，然而，在架构活动中，对业务及其需求的深入理解并不常见，进而被认为为业务增值，而且太慢了。于是，很多人把敏捷作为救命稻草，认为“最好的架构,需求和设计来自于自组织团队。”团队往往在专注于更快的交付功能，代价就是不断推迟技术债务和技术特性。于是，一些敏捷途径和方法论已经开始包含正式的架构活动与步骤。

借鉴敏捷原则的定义方式，满足以下六个简单准则的就可以被称作持续架构：

• 准则1：用产品思维，而非项目思维来设计架构。从产品的角度来构建比单纯设计点解决方案更有效率，更容易让团队专注于客户的需求。
• 准则2：聚焦质量属性，而不仅仅是功能性需求。质量属性需求驱动着架构。
• 准则3：在绝对必要的时候再做设计决策。设计架构取决于事实，而不是猜测。设计和实施可能永远都用不到的功能是无意义的，是对时间和资源的浪费。
• 准则4：利用“微小的力量”，面向变化来做架构设计。大的，单体的，紧耦合的组件很难改变。相反，应该使用小且松散耦合的软件元素。
• 准则5：为构建，测试，部署和运营来设计架构。大多数架构方法只关注软件构建活动，但我们认为架构师也应该关注测试,部署和运营，以支持持续交付。
• 准则6：在完成系统设计后，开始为团队做组织建模。团队的组建方式驱动着系统的架构和设计。

持续架构不是一种方法论，而是一组准则，工具，技术和想法，可以被视为架构师有效处理持续交付项目的工具集。

持续架构的目标是客户需求和交付能力的平衡，以创建一个连贯、可持续的系统，该系统不仅应满足其功能要求，还应满足相关的质量属性，例如安全性、性能、可伸缩性、弹性、数据等等。应用持续架构的方法如下图所示