💡 什麼是萬物皆代碼？
萬物皆代碼是一種範式，將軟體開發、交付或營運的任何方面視為代碼工件，可以使用與應用程式代碼相同的工具和流程進行版本控制、測試和部署。
在雲端運算、自動化和 DevSecOps 時代，「萬物皆代碼」或簡稱「即代碼」的概念變得越來越流行和相關。但這意味著什麼，採用它有什麼好處和挑戰？
🧬 你知道嗎？
生命即代碼就是基因組。正如 DNA 編碼建構和操作生物體的指令一樣，「即代碼」編碼建構和操作軟體系統的指令。兩者都是版本化的（透過進化或版本控制）、測試的（透過自然選擇或自動化測試）和部署的（透過繁殖或持續部署）。
即代碼涵蓋各個領域，例如：
- 基礎設施即代碼（IaC）：使用配置檔案或腳本定義和管理雲端資源（如伺服器、網路和儲存）的實踐。Terraform 是基礎設施即代碼的最佳代表。
- 策略即代碼：將安全、合規或治理規則表達為代碼並強制執行的實踐，可以整合到開發和部署管道中。
- 架構即代碼：使用基於代碼的格式定義和記錄軟體架構決策、模式和結構的實踐，可以進行版本控制和驗證。像 Structurizr 和 C4 模型這樣的工具使架構師能夠以程式化方式描述系統架構，確保架構文件與實作保持同步。
- 圖表即代碼：使用可以渲染成圖形格式的代碼建立和更新圖表（如架構圖或流程圖）的實踐。
- 簡報即代碼：使用可以轉換為不同格式或平台的代碼建立和更新簡報（如投影片或報告）的實踐。slidev 是其中一個工具，但 HTML/CSS/JS 和 VBA 可能是可讀性較差的替代方案。
- 資料庫即代碼：使用可以由資料庫引擎或工具執行的代碼定義和管理資料庫模式、資料和遷移的實踐。
- 文件即代碼：使用純文字格式（如 Markdown 或 AsciiDoc）編寫和維護文件的實踐，可以由文件產生器處理或整合到代碼儲存庫中。有無數框架可以從程式設計師友善的代碼產生人類可讀的文件。
- 配置管理即代碼：使用可以動態或靜態應用的代碼定義和管理應用程式設定（如環境變數或功能標誌）的實踐。
- UI 即代碼：使用可以渲染到不同裝置或平台的代碼建立和更新使用者介面（如網頁或行動應用）的實踐。UI 通常使用 XML 和 HTML 儲存，但從程式語言產生也並不罕見。
- AI 即代碼：使用可以使用 AI 框架或平台訓練和部署的代碼建立和更新人工智慧模型（如機器學習或深度學習模型）的實踐。同時，模型可以透過推理「分層」。Ollama 具有類似 Dockerfile 的即代碼，除了系統提示外，還可以用於該目的。
即代碼的主要優勢：
- 一致性：即代碼確保軟體開發、交付或營運的所有方面彼此一致，並與應用程式代碼一致。這減少了可能由手動或臨時干預引起的錯誤、衝突和差異。
- 可重用性：即代碼使代碼工件能夠在不同的專案、環境或團隊之間重用。這提高了開發者和營運者之間的效率、生產力和協作。
- 可追溯性：即代碼提供了對軟體開發、交付或營運任何方面所做變更的清晰完整歷史記錄。這有助於稽核、除錯和排查軟體生命週期中可能發生的問題。
- 可擴展性：即代碼允許輕鬆快速地擴展雲端資源、工作流程或模型以滿足不斷變化的需求或要求。這提高了軟體系統的效能、可用性和彈性。
- 自動化：即代碼使原本繁瑣、耗時或容易出錯的任務自動化。這使開發者和營運者能夠專注於更具創造性或策略性的活動。
- AI 友善：即代碼提供結構化、機器可讀的格式，AI 系統可以輕鬆解析、理解和產生。這使 AI 助手能夠幫助建立、修改和最佳化基礎設施、文件、配置和其他工件，加速開發工作流程並減少人為錯誤。
即代碼的主要挑戰：
- 複雜性：即代碼為軟體開發、交付或營運引入了額外的抽象和複雜性層。這要求開發者和營運者學習新技能、工具和語言來處理不同領域的即代碼。
- 整合：即代碼需要整合各種工具和平台以支援不同領域的即代碼。這可能會給開發者和營運者帶來相容性問題、安全風險或維護開銷。
- 測試：大多數即代碼需要對代碼工件進行嚴格測試以確保其正確性、可靠性和品質。這可能需要開發者和營運者額外的資源、時間或專業知識。
是否合理？
對於每個用例使用即代碼是否合理？答案取決於幾個因素，例如：
- 專案的性質和範圍：某些專案可能比其他專案更受益於即代碼，這取決於它們的規模、複雜性或領域。例如，大規模、分散式或資料密集型專案可能比小規模、單體或邏輯密集型專案更受益於 IaC、WaC 或 AIC。
- 工具和平台的成熟度和可用性：某些工具和平台可能比其他工具和平台更好地支援即代碼，這取決於它們的功能、功能性或相容性。例如，某些雲端提供商可能為 IaC 提供更多選項和靈活性，或某些 AI 框架可能為 AIC 提供更多功能和效能。
- 開發者和營運者的技能和偏好：某些開發者和營運者可能比其他人更喜歡即代碼，這取決於他們的技能、經驗或風格。例如，某些開發者可能更喜歡編寫代碼而不是使用圖形介面，或某些營運者可能更喜歡使用代碼而不是使用儀表板。
各領域即代碼的狀態
📊 即代碼成熟度評估
基於當前產業採用和工具成熟度：
| 即代碼 | 狀態 | 合理性（最高 5 星） |
|---|---|---|
| 基礎設施 | 非常成熟且廣泛使用 | ⭐⭐⭐⭐⭐ |
| 策略 | 成熟但未被廣泛使用 | ⭐⭐⭐ |
| 架構 | 隨著 Structurizr 和 C4 等工具的採用而增長 | ⭐⭐⭐⭐ |
| 圖表 | 取決於圖表類型。有些難以調整佈局 | ⭐⭐⭐ |
| 簡報 | 難以微調佈局和建立動畫 | ⭐ |
| 資料庫 | ⭐⭐⭐⭐⭐ | |
| 文件 | Markdown 等 | ⭐⭐⭐⭐ |
| 配置 | ⭐⭐⭐ | |
| UI | 可以用程式語言產生 | ⭐⭐⭐⭐ |
| AI | 模型可以分層 | ⭐⭐ |
圖表即代碼資源
Mermaid JS
在 YAML 語言中表示圖表即代碼的最佳方式是透過 MermaidJS，這是一個可以即時產生圖表的 JavaScript 函式庫。GitHub 和許多平台原生支援 MermaidJS。其他平台如 Hexo（產生此部落格）也有外掛來使用 MermaidJS 渲染圖表。與其他圖表即代碼函式庫相比，錯誤訊息非常直觀。強烈推薦用於編寫簡單圖表。
PlantUML
https://github.com/plantuml/plantuml
一個知名的圖表即代碼產生器，從人類可讀的語言產生圖像。即使在處理 Java 程式時，它也以可容忍的速度產生圖像。此工具支援多頁圖表。然而，即使它支援各種佈局類型，掌握定位也可能具有挑戰性。隨著圖表變得更複雜，線條可能會覆蓋標籤，並可能出現其他問題。
AWS Diagram-as-Code
https://github.com/awslabs/diagram-as-code
該專案始於 2024 年 2 月，相對較新。圖表看起來很好，帶有圖示和分組：
雖然它使用 YAML，但一旦開始設定資源之間的連結，使用其結構編寫圖表可能會很痛苦。你需要至少寫四行來有效地描述它們，例如 Source、Target、SourcePosition 和 TargetPosition。
不推薦，除非你想從 CloudFormation 中的基礎設施即代碼快速產生圖表，或從 Terraform 轉換。然而，你仍然需要大量工作來完成圖表。
結論
總之，即代碼是一種強大且有前途的範式，可以增強軟體開發、交付或營運。然而，它也帶來了自己的挑戰和權衡，在採用之前需要仔細考慮。
🎯 關鍵要點
即代碼不是一刀切的解決方案，而是一個依賴於上下文的選擇，取決於專案、工具和相關人員。