💡 什么是万物皆代码？
万物皆代码是一种范式，将软件开发、交付或运营的任何方面视为代码工件，可以使用与应用程序代码相同的工具和流程进行版本控制、测试和部署。
在云计算、自动化和 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 转换。然而，你仍然需要大量工作来完成图表。
结论
总之，即代码是一种强大且有前途的范式，可以增强软件开发、交付或运营。然而，它也带来了自己的挑战和权衡，在采用之前需要仔细考虑。
🎯 关键要点
即代码不是一刀切的解决方案，而是一个依赖于上下文的选择，取决于项目、工具和相关人员。