信息技術是一個日新月異的領域，從自身的發展到學科的教程，再到應用場景的無處不在，導致每天甚至每時每刻都可能會有新的技術或者新的方法涌現出來。

“吾生也有涯，而知也無涯”，那么，對于一個工程師而言，不了解并學習持續架構會落伍么？

不學習就會落伍

在前不久QCon2022（ 由于疫情的原因延遲到今年舉辦）上有個分論壇主題是“工程師成長實戰”，無論是宗剛老師的《三倍速成長實現職場躍遷》，還是《Maven實戰》作者許曉斌的《技術領導力實戰》，或是老媽農自己分享的《QCon：工程師成長的金字塔思維?》，都涉及了一個同樣的主題——學習。

對一個IT從業者，尤其是一名軟件工程師，對自己而言，需要不斷成長才能提高自己的適應能力以及市場的競爭力，才能坦然地面對所謂的“35歲危機”；對企業而言，只有不斷地成長才能持續地為企業創造價值。不斷地成長，離不開學習，對于我們每個人而言，可能是終身學習。

那么如何學習呢？

在老碼農自己的分享中，描述了關于學習的金字塔模型，將學習方式分為了三個方式：輸入、消化和輸出。盡管主動學習優于被動學習，很多的學習都是從輸入開始，根源上都是從問題開始的，而閱讀是學習方式中非常重要的一種方法。在計算機領域的思維范式金字塔中，歷史思維是其中的一個支點，“治學先治史”，所謂治史離不開閱讀。

或許，每個人都知道學習的重要性，但面對浩如煙海的知識，我們學習什么呢？

學習什么？

學習什么取決于學習的目的，不是為了學習而學習，不能把手段當目的。學習的目的是為了更好地解決問題，分析并解決問題才是價值所在，而個人的成長可能只是學習目的的一部分或者副產品。

“知人者智，知己者明”，有時候，發現問題比解決問題更困難。提出一個好問題是一件有挑戰的事情，因為答案往往就在問題當中。對于我們軟件工程師來說，有很多問題都會落到軟件工程領域，例如軟件架構。

如果把問題比喻成病痛，那么解決問題則類似于治病。在《扁鵲見蔡恒公》中有“君有疾在腠理，不治將恐深”，很多致命的問題可能都是小問題日積月累形成的。而治病的更高境界可能是“治未病”，即“防患未然”。然而，我們常見的情形往往是“曲突徙薪忘恩澤，焦頭爛額為上客”。基于個人和環境的局限，我們的預見能力可能非常有限。

但是，我們可以通過學習，參考業界對未來的遇見，幫助我們提升洞察力，例如Gartner 對技術趨勢的預測。2023年， Gartner 對十大戰略技術趨勢的預測如下：

• 數字免疫系統
• 應用可觀測性
• AI信任、風險和安全管理
• 行業云平臺
• 平臺工程
• 無線價值實現
• 超級應用
• 自適應人工智能
• 元宇宙
• 可持續技術

這十大技術趨勢劃分為優化、開拓、擴展三大主題，其中，優化包括：數字免疫系統、應用可觀測性、AI信任、風險和安全管理；開拓包括：元宇宙、超級應用、自適應AI；擴展包括：行業云平臺、平臺工程、無線價值實現。而可持續性技術貫穿2023年的所有戰略技術趨勢。那么，什么樣的可持續性技術會貫穿所有的領域呢？聚焦在軟件工程的話，恐怕應該是持續架構了。

從架構到持續架構

軟件架構是客觀存在的， 不論你是否主觀情愿，它都在那里。然而，架構一詞源自隱喻（關于隱喻的學習與思考?），所以對軟件架構的范圍，人們往往有著不同的看法。例如，宏觀的系統結構，把架構認為是一個軟件系統的高級抽象，由一組計算組件和描述這些組件之間交互的連接器組成；那些對系統及其涉眾有重大影響的決策；作為系統和開發項目的藍圖等等。

老碼農喜歡用時空觀來分析問題，在《如何進入一個新領域?》以及《面向全棧的技術管理?》有過描述。一般地，對于軟件架構而言，從空間視角來看是軟件系統的體系架構，例如架構模式（?軟件架構的10個常見模式?）等；從時間視角來看是架構決策和實現流程。實際上，軟件架構是時空視角的結合與統一，也就是說，在一般意義上，軟件架構是指軟件系統的基本結構以及創建這種結構和系統的規程。

令人困擾的事，基于時間的單向性和動態性，與時間相關的軟件流程乃至所謂的“最佳實踐”有時候往往又會成為生產力的約束。老碼農個人認為，持續架構以及可持續性技術都是對時間視角架構問題的積極探索和實踐，并且涵蓋了空間視角架構的大多數方法。

什么是持續架構呢？這需要從明確架構活動開始——

軟件架構是由業務目標所驅動，然而，在架構活動中，對業務及其需求的深入理解并不常見，進而被認為為業務增值，而且太慢了。于是，很多人把敏捷作為救命稻草，認為“最好的架構,需求和設計來自于自組織團隊。”團隊往往在專注于更快的交付功能，代價就是不斷推遲技術債務和技術特性。于是，一些敏捷途徑和方法論已經開始包含正式的架構活動與步驟。

借鑒敏捷原則的定義方式，滿足以下六個簡單準則的就可以被稱作持續架構：

• 準則1：用產品思維，而非項目思維來設計架構。從產品的角度來構建比單純設計點解決方案更有效率，更容易讓團隊專注于客戶的需求。
• 準則2：聚焦質量屬性，而不僅僅是功能性需求。質量屬性需求驅動著架構。
• 準則3：在絕對必要的時候再做設計決策。設計架構取決于事實，而不是猜測。設計和實施可能永遠都用不到的功能是無意義的，是對時間和資源的浪費。
• 準則4：利用“微小的力量”，面向變化來做架構設計。大的，單體的，緊耦合的組件很難改變。相反，應該使用小且松散耦合的軟件元素。
• 準則5：為構建，測試，部署和運營來設計架構。大多數架構方法只關注軟件構建活動，但我們認為架構師也應該關注測試,部署和運營，以支持持續交付。
• 準則6：在完成系統設計后，開始為團隊做組織建模。團隊的組建方式驅動著系統的架構和設計。

持續架構不是一種方法論，而是一組準則，工具，技術和想法，可以被視為架構師有效處理持續交付項目的工具集。

持續架構的目標是客戶需求和交付能力的平衡，以創建一個連貫、可持續的系統，該系統不僅應滿足其功能要求，還應滿足相關的質量屬性，例如安全性、性能、可伸縮性、彈性、數據等等。應用持續架構的方法如下圖所示