信息技术是一个不断变化的领域。从自身的发展到学科教程再到应用场景的无处不在，每天甚至每时每刻都可能出现新技术或新方法。“我的生命是有限的，但知识是无限的。”那么，对于一个工程师来说，如果不了解和学习持续架构，会不会落后呢？如果你不学习，你就会落后。前不久QCon2022（因疫情推迟到今年），有一个主题为“工程师的实践成长”的分论坛，无论是宗刚的《三倍速成长实现职场跃迁》，还是《Maven实战》的作者徐晓斌的，或者老马农自己分享的《QCon：工程师成长的金字塔思维?》，都是同一个主题——学习。对于IT从业者，尤其是软件工程师来说，对于自己来说，需要不断成长，提高自身的应变能力和市场竞争力，才能从容面对所谓的“35岁危机”；，只有不断成长，才能不断为企业创造价值。持续的成长离不开学习。对于我们每个人来说，这可能是终身学习。那么如何学习呢？在老coder自己的分享中，他描述了学习的金字塔模型，将学习方式分为输入、消化、输出三种方式。主动学习虽然比被动学习好，但是很多学习都是从输入开始的，根源是从提问开始的，而阅读是学习方法中非常重要的一个方法。在计算机领域的思维范式金字塔中，历史思维是支点之一，“学学先治史”，所谓历史离不开阅读。或许，人人都知道学习的重要性，但面对浩如烟海的知识，我们学什么呢？学什么学什么要看学习的目的，不能为了学习而学习，不能把手段当成目的。学习的目的是为了更好地解决问题，分析和解决问题才是价值所在，个人成长可能只是学习目的的一部分或副产品。“知人者智，自知者智”。有时候，发现问题比解决问题更困难。提出一个好问题具有挑战性，因为答案通常就在问题中。对于我们软件工程师来说，有很多问题都属于软件工程领域，比如软件架构。如果把问题比作疾病，那么解决问题就类似于治愈疾病。《扁鹊见蔡恒公》中有“有病就怕”的说法。许多致命的问题可能是小问题日积月累造成的。治疗的更高境界可能是“防病于未然”，即“防病于未然”。然而，我们的共同处境往往是“薪转忽恩忘，客欲绝”。基于个人和环境的限制，我们的预见能力可能非常有限。但是，我们可以学习和参考行业与未来的遭遇，帮助我们提高洞察力，比如Gartner对技术趋势的预测。Gartner预测2023年十大战略技术趋势如下：数字免疫系统应用可观测性AI信任、风险与安全管理行业云平台平台工程无线价值实现超级应用自适应人工智能元界可持续技术这十大技术趋势分为三大主题：优化、发展、扩张。其中，优化包括：数字免疫系统、应用可观察性、AI信任、风险和安全管理；开发内容包括：元界、超级应用、自适应AI；拓展包括：行业云平台、平台工程、无线价值实现。而可持续技术贯穿到2023年的所有战略技术趋势。那么，什么样的可持续技术会横跨所有领域呢？如果专注于软件工程，恐怕应该是持续架构。从架构到持续架构软件架构是客观存在的，不管你愿不愿意，它都存在。然而，架构一词源于一个隐喻（Learningandthinkingaboutmetaphors），因此人们对软件架构的范围往往有不同的看法。例如，宏观系统结构，将体系结构视为软件系统的高级抽象，由一组计算组件和描述这些组件之间交互的连接器组成；那些对系统及其利益相关者有重大影响的决定；作为系统和开发项目的蓝图等等。老码农喜欢用时空的概念来分析问题，在《如何进入一个新领域?》和《面向全栈的技术管理?》中都有介绍。一般来说，对于软件架构来说，就是从空间角度对软件系统的架构，比如架构模式（软件架构的10种常见模式）等；从时间上看，是架构的决策和实施过程。实际上，软件体系结构是时间和空间视角的结合和统一，也就是说，从广义上讲，软件体系结构是指软件系统的基本结构以及创建这种结构和系统的过程。麻烦的是，基于时间的单向性和动态性，与时间相关的软件过程甚至所谓的“最佳实践”往往成为生产力的制约因素。老码农个人认为，持续架构和可持续技术是对时间视角架构问题的积极探索和实践，涵盖了空间视角架构的大部分方法。什么是连续架构？这需要从明确的架构活动开始——软件架构是由业务目标驱动的，然而，在架构活动中，对业务及其需求的深刻理解通常不会被视为为业务增加价值，而且速度太慢。于是，很多人将敏捷视为救命稻草，认为“最好的架构、需求和设计都来自自组织的团队”。团队通常以不断推迟技术债务和技术功能为代价，专注于更快地交付功能。因此，一些敏捷方法和方法论已经开始包括正式的架构活动和步骤。借鉴敏捷原则的定义，满足以下六个简单标准的连续架构可以称为持续架构：原则一：以产品思维而非项目思维设计架构。从产品的角度构建比简单地设计点解决方案更有效，并且使团队更容易专注于客户需求。准则2：关注质量属性，而不仅仅是功能需求。质量属性需求驱动架构。规则3：仅在绝对必要时才做出设计决策。设计架构基于事实，而不是猜测。设计和实现可能永远不会使用的功能是毫无意义的，而且是在浪费时间和资源。原则四：用“小功率”来设计变化的架构。大型、单体、紧密耦合的组件很难更改。相反，使用小型且松散耦合的软件元素。原则5：为构建、测试、部署和操作设计架构。大多数架构方法只关注软件构建活动，但我们认为架构师还应该关注测试、部署和操作以支持持续交付。准则6：完成系统设计后，开始对团队进行组织建模。团队的组成方式驱动着系统的架构和设计。持续架构不是一种方法论，而是一组指南、工具、技术和思想，可以被视为架构师有效处理持续交付项目的工具集。持续架构的目标是平衡客户需求和可交付成果，以创建一个连贯的、可持续的系统，该系统不仅满足其功能要求，而且满足相关的质量属性，如安全性、性能、可扩展性、弹性、数据等。应用连续架构的方法如下图所示
