大家好。 期待課程開課 , 傳統上與大家分享有用素材的翻譯。
軟件解決越來越多的日常任務，同時變得越來越複雜。 正如 Marc Andressen 曾經說過的，它吞噬了世界。
因此，應用程序的開發和交付方式在過去幾年發生了巨大變化。 這些是導致一系列原則的構造尺度的變化。 這些原則已被證明有助於團隊建設、設計、開發以及將您的應用程序交付給最終用戶。
原則可歸納如下： 應用程序應該是小的，基於網絡的，並且有一個以開發者為中心的架構. 牢記這三個原則，您可以創建一個健壯的端到端應用程序，該應用程序可以快速安全地交付給最終用戶，並且易於擴展和擴展。
每個提議的原則都有許多方面，我們將討論這些方面，以展示每個原則如何有助於最終目標，即快速交付易於維護和使用的可靠應用程序。 我們將查看與它們的對立面相關的原則，以闡明其含義，例如，“確保您使用 小原則“。
我們希望本文能鼓勵您使用建議的原則來構建現代應用程序，這將在不斷增長的技術堆棧的背景下提供統一的設計方法。
通過應用這些原則，您會發現自己利用了軟件開發的最新趨勢，包括 到應用程序的開發和交付，容器的使用（例如， ) 和容器編排框架（例如， ），微服務的使用（包括微服務架構 и 對於微服務應用程序。
什麼是現代應用程序？
現代應用？ 現代堆棧？ “現代”到底是什麼意思？
大多數開發人員對現代應用程序由什麼組成只有一個大概的概念，因此有必要明確定義這個概念。
現代應用程序支持多個客戶端，無論是 React JavaScript 庫用戶界面、Android 或 iOS 移動應用程序，還是連接到另一個 API 的應用程序。 現代應用程序意味著它為無限數量的客戶端提供數據或服務。
現代應用程序提供 API 來訪問請求的數據和服務。 API 應該是不可變的和常量的，而不是專門為來自特定客戶端的特定請求而編寫的。 API 通過 HTTP(S) 可用，並提供對 GUI 或 CLI 中可用的所有功能的訪問。
數據必須以普遍接受的、可互操作的格式（例如 JSON）提供。 API 以乾淨、有組織的方式公開對象和服務，例如 RESTful API 或 GraphQL 提供了一個體面的接口。
現代應用程序建立在現代堆棧之上，現代堆棧是分別支持此類應用程序的堆棧。 該堆棧允許開發人員輕鬆創建具有 HTTP 接口和清晰的 API 端點的應用程序。 所選擇的方法將允許您的應用程序輕鬆地接收和發送 JSON 格式的數據。 換句話說，現代堆棧對應於十二要素應用程序的元素 .
此類堆棧的流行版本基於 , , , , и . 微服務架構 表示以上述每種語言實現的現代堆棧的示例。
請注意，我們並不是在提倡一種專門的微服務方法。 你們中的許多人都在使用需要發展的整體，而其他人則在處理正在擴展和發展成為微服務應用程序的 SOA 應用程序。 還有一些正在轉向無服務器應用程序，還有一些正在實施上述組合。 文章中概述的原則適用於這些系統中的每一個，只需進行一些小的修改。
原則
現在我們對什麼是現代應用程序和現代堆棧有了共同的理解，是時候深入研究架構和開發原則，它們將為您開發、實施和維護現代應用程序提供良好的幫助。
原則之一聽起來像“製作小型應用程序”，我們就稱它為 小原則. 有非常複雜的應用程序，它們由許多活動部件組成。 反過來，從小的、離散的組件構建應用程序可以更容易地設計、維護和使用它作為一個整體。 （請注意，我們說的是“簡化”而不是“使簡單”）。
第二個原則是，我們可以通過幫助開發人員專注於他們正在開發的功能來提高開發人員的工作效率，同時讓他們在實施過程中擺脫對基礎設施和 CI/CD 的擔憂。 所以，簡而言之，我們的方法 專注於開發人員.
最後，您的應用程序的所有內容都必須連接到網絡。 在過去的 20 年裡，隨著網絡變得更快、應用程序變得更複雜，我們已經朝著網絡化的未來邁進了一大步。 正如我們已經看到的，現代應用程序必須由許多不同的客戶端通過網絡使用。 將網絡思維應用於架構具有與 小原則 和方法的概念， 面向開發者.
如果您在設計和實施應用程序時牢記這些原則，您將在產品的開發和交付中擁有不可否認的優勢。
讓我們更詳細地了解這三個原則。
小原則
人腦很難同時感知大量信息。 在心理學中，術語認知負荷是指將信息保留在記憶中所需的精神努力總量。 減少開發人員的認知負擔是當務之急，因為這使他們能夠專注於解決問題，而不是將整個應用程序的當前複雜模型和正在開發的功能留在腦海中。
應用程序分解的原因如下：
- 減少開發人員的認知負擔；
- 加速和簡化測試；
- 快速交付應用程序中的更改。
有幾種方法可以減少開發人員的認知負擔，這就是小原則發揮作用的地方。
因此，這裡有三種減少認知負荷的方法：
- 減少他們在開發新功能時必須考慮的時間範圍——時間範圍越短，認知負荷越低。
- 減少執行一次性工作的代碼量 - 更少的代碼 - 更少的負載。
- 簡化對應用程序進行增量更改的過程。
縮短開發時間
讓我們回到方法論的時代 waterfall 是開發過程的標準，開發或更新應用程序的時間範圍為六個月到兩年是常見的做法。 通常，工程師會先閱讀相關文檔，例如產品需求 (PRD)、系統參考文檔 (SRD)、架構藍圖，然後開始將所有這些內容組合成一個認知模型，並據此進行編碼。 隨著需求的變化以及隨之而來的架構的變化，必須做出認真的努力來通知整個團隊關於認知模型的更新。 這種方法在最壞的情況下只會使工作癱瘓。
應用程序開發過程中最大的變化是引入了敏捷方法。 該方法的主要特徵之一 agile 是迭代開發。 反過來，這會減少工程師的認知負擔。 無需開發團隊在一個漫長的周期內實現應用程序， agile 方法使您可以專注於可以快速測試和部署的少量代碼，同時還可以接收反饋。 該應用程序的認知負荷已從六個月轉變為兩年時間框架，其中包含大量規範，用於兩週的添加或功能更改，目標是對大型應用程序的理解更加模糊。
將重點從大型應用程序轉移到可以在兩週衝刺中完成的特定小功能，並且在下一個衝刺之前只考慮一個功能，這是一個重大變化。 這使我們能夠提高開發效率，同時減少不斷波動的認知負荷。
在方法論上 agile 最終的應用程序預計是原始概念的略微修改版本，因此開發的終點必然是模棱兩可的。 只有每個特定衝刺的結果才能清晰準確。
小型代碼庫
減少認知負荷的下一步是減少代碼庫。 通常，現代應用程序非常龐大——一個健壯的企業應用程序可能包含數千個文件和數十萬行代碼。 根據文件的組織方式，代碼和文件之間的鏈接和依賴關係可能很明顯，反之亦然。 甚至調試代碼執行本身也可能存在問題，這取決於所使用的庫以及調試工具對庫/包/模塊和自定義代碼的區分程度。
構建應用程序代碼的工作心智模型可能會花費大量時間，並再次給開發人員帶來巨大的認知負擔。 對於單體代碼庫尤其如此，其中有大量代碼，其功能組件之間的交互沒有明確定義，並且由於不尊重功能邊界，關注對象的分離往往很模糊。
減少工程師認知負擔的有效方法之一是轉向微服務架構。 在微服務方法中，每個服務都專注於一組功能； 而服務的含義通常是定義好的並且可以理解的。 服務的邊界也很明確——記住與服務的通信是通過 API 完成的，因此一個服務生成的數據可以很容易地傳遞給另一個服務。
與其他服務的交互通常僅限於一些用戶服務和一些使用簡單乾淨的 API 調用的提供者服務，例如使用 REST。 這意味著工程師的認知負擔大大降低。 最大的挑戰仍然是理解服務交互模型以及諸如交易之類的事情是如何在多個服務之間發生的。 因此，微服務的使用通過減少代碼量、定義清晰的服務邊界以及提供對用戶和提供者之間關係的理解來減少認知負荷。
小的增量變化
原則的最後一個要素 小 是變更管理。 對於開發人員來說，查看代碼庫（甚至可能是他們自己的舊代碼）並說，“這太糟糕了，我們需要全部重寫”是一種特別的誘惑。 有時這是正確的決定，有時則不然。 它將全局模型更改的負擔放在開發團隊身上，進而導致巨大的認知負擔。 工程師最好專注於他們在衝刺期間可以做出的改變，這樣他們就可以及時推出必要的功能，儘管是逐步的。 最終產品應類似於預先計劃的產品，但要進行一些修改和測試以滿足客戶的需求。
當重寫大部分代碼時，有時無法快速交付更改，因為其他系統依賴性會起作用。 為了控制更改流，您可以使用功能隱藏。 原則上，這意味著該功能已投入生產，但無法使用環境變量設置 (env-var) 或其他一些配置機制。 如果代碼已通過所有質量控制流程，那麼它可能會以潛在狀態結束生產。 但是，此策略僅在最終啟用該功能時才有效。 否則，它只會使代碼混亂並增加開發人員為了提高工作效率而必須處理的認知負擔。 變更管理和增量變更本身有助於將開發人員的認知負擔保持在可承受的水平。
即使簡單地引入附加功能，工程師也必須克服許多困難。 在管理層方面，謹慎的做法是減少團隊不必要的負擔，以便團隊可以專注於關鍵的職能要素。 您可以做三件事來幫助您的開發團隊：
- 使用方法
agile限制團隊必須專注於關鍵功能的時間範圍。 - 將您的應用程序實現為多個微服務。 這將限制可以實現的功能數量，並強化保持認知負荷的界限。
- 比起大而笨重的增量更改，更喜歡更改小塊代碼。 使用功能隱藏來實現更改，即使它們在添加後不會立即可見。
如果你在工作中應用小原則，你的團隊會更快樂，更專注於實現必要的功能，並且更有可能更快地推出質的變化。 但這並不意味著工作不能變得更複雜，有時，相反，引入新功能需要修改幾個服務，這個過程可能比單體架構中的類似過程更困難。 無論如何，採用小規模方法的好處是值得的。
第一部分結束。
很快我們將發布翻譯的第二部分，現在我們正在等待您的評論並邀請您 ，將於今天 20.00:XNUMX 舉行。
來源： www.habr.com