{"id":13602979,"url":"https://github.com/phodal/cloud-dev","last_synced_at":"2026-02-17T17:33:15.273Z","repository":{"id":150636948,"uuid":"229754766","full_name":"phodal/cloud-dev","owner":"phodal","description":"云研发，是一种生于云上的闭环 + 代码化的软件开发方式。它可以让业务人员、开发人员、运营人员等在同一个云端共同协作、透明化地完成整个软件的生命周期（需求、设计、编码、构建、部署、运营），而非相互隔离，又或者是借助于多个软件才能完成工作。","archived":false,"fork":false,"pushed_at":"2021-10-28T14:14:23.000Z","size":1569,"stargazers_count":232,"open_issues_count":1,"forks_count":34,"subscribers_count":9,"default_branch":"master","last_synced_at":"2025-10-08T07:28:51.409Z","etag":null,"topics":["dsl","pipeline","serverless"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/phodal.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2019-12-23T13:07:23.000Z","updated_at":"2025-07-21T09:01:59.000Z","dependencies_parsed_at":"2023-05-26T23:30:12.208Z","dependency_job_id":null,"html_url":"https://github.com/phodal/cloud-dev","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/phodal/cloud-dev","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phodal%2Fcloud-dev","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phodal%2Fcloud-dev/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phodal%2Fcloud-dev/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phodal%2Fcloud-dev/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/phodal","download_url":"https://codeload.github.com/phodal/cloud-dev/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/phodal%2Fcloud-dev/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29551257,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-17T14:33:00.708Z","status":"ssl_error","status_checked_at":"2026-02-17T14:32:58.657Z","response_time":100,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dsl","pipeline","serverless"],"created_at":"2024-08-01T18:01:45.354Z","updated_at":"2026-02-17T17:33:15.248Z","avatar_url":"https://github.com/phodal.png","language":null,"funding_links":[],"categories":["Others","Document"],"sub_categories":["Operations"],"readme":"# 云研发：研发即代码\n\n相近文章，云研发架构：《[Water 云研发架构模式](https://github.com/phodal/water/)》\n\n微信群：请添加 `phodal02` 为好友，注明：`云研发`。\n\n如你所见，在过去的几年里，发生了快速的变化（这句话，我已经说烂了）。好比如说：\n\n - 编程门槛的降低。大量的低编程能力水平可以进入这个行业（如上一篇文章）\n - 基础设施的完善。只需要执行 ``git push``，便能完成 `push to production`（尽管四年前我们在项目上实践过）\n - 云主机开发。远程开发机器，代码不在本地机器上。\n - 多人实时开发编辑技术。诸如于 Visual Studio Live Share，可以多人实时协作编程。\n - 5G。更快速的网络连接，更好的通信质量。\n - ……。\n\n在经历了与公司大佬、同事、社区大佬等的一系列的技术讨论之后，以及近年来开始云代码开发，我又有了一些新的顿悟。于是，我就撸了这篇文章。\n\n在你失去继续往下阅读的兴趣之前，让我先说第一个结论：\n\n\u003e 云研发，是一种生于云上的**闭环** + **代码化**的软件开发方式。它可以让业务人员、开发人员、运营人员等在同一个云端**共同协作**、**透明化**地完成整个软件的生命周期（需求、设计、编码、构建、部署、运营），而非相互隔离，又或者是借助于多个软件才能完成工作。\n\n因此云研发是一种解决方案，它解决的问题是：如何以更高效地方式进行软件开发？ \n\n作为 v0.1.0 的定义，我对它的定义可能还不是非常准确，但是重点有这么几个：\n\n - 以**共同协作**的方式开发软件\n - 软件开发的在线闭环\n - 应用生命周期的代码化和可追溯\n\n你看吧，我们过去解决了一个又一个的线下协作问题，现在构建新的线上协作平台的时机已经逐渐成熟了，是时候开始准备构建你们的云研发平台。\n\n我知道你想说市面上已经有这样的工具，比如 xx 的 xx。但是，一来它朝着一个错误的方向前进，你知道的某公司更懂 2B；二来，它包含了大量的功能，但是却没有闭上环。当然了，我只是从官方的首页看到的功能，一眼得到这个所谓的结论。 \n\nPS：只要是它们没办法体现我总结的核心三要素，笑~。套不上我的理论，他们一定是错的，手动滑稽，逃~。\n\n![核心三要素](images/core.jpg)\n\n## 引子 1：核心三要素\n\n我不想多说废话了，手疼。\n\n如果基础设施真的已经是基础设施，那么你不应该在云平台强调它们。这就是为什么尽管基础设施很重要，但是却不是核心要素之一。基础设施已经是一个通用域，作为一家时髦的公司，如果你们还没有……。\n\n### 微架构\n\n\u003e 微架构，即以模块化的组合方式协同构建大型应用（前端、后端、APP等）的架构方式。每个微应用都可以独立开发、独立部署、独立运行，对应的替换的方式有模块化、子模块的方式，微服务、APP 插件化（独立构建、独立运行）、微前端等。\n\n微架构是一个模式，它不是银弹，它以技术的方式拆解了复杂软件架构，适合于复杂场景下的问题，还有人类脑容易不够大的问题。\n\n#### 后端：服务导向架构\n\n五年前，Martin Fowler 和 James Lewis 一起写下了那篇《[微服务架构](https://martinfowler.com/articles/microservices.html)》，微服务成为了今天新项目的主流架构之一。最近几年来，它结合着《[领域驱动设计](https://www.phodal.com/blog/use-ddd-reduce-software-cost/)》这把锤子，已经成为了一个利器。\n\n作为服务导向架构的一种实现方式，掌握它背后的设计与实现模式，是云研发中不可或缺的重要一环。\n\n####  后端：函数即服务\n\n两年多以前，我在 GitHub 写下了我的第 N 本电子书《[Serverless 架构应用开发指南](https://serverless.ink/)》，而在最近 Serverless 终于在国内慢慢有一点的热度。两年前，我陆续收到阿里云、腾讯云的 Serverless 尝鲜体验（作为一个 MVP 还是没白混），但是它们并不成熟，甚至于无法调用自己的云服务。而今天，越来越多的云厂商的 Serverless 终于可以跑起来了，\n\n同理于服务导向架构 BAAS （Backend as a service）又或者是 Serverless，也是如此，它们进一步拆解了复杂问题到人能 handle 的范围。\n\n#### APP：应用即『插件』\n\n最近几年，对于 APP 来说，开发者也探索出了大量的微架构方案。我习惯地称它们为应用即『插件』，因为 APP 作为一个基座，提供了各式各样的能力。就目前来说有三种展现方式：\n\n - APP 内 Web 应用。\n - APP 插件化。市面上已经有大量这一类的方案，诸如于 RePlugin、Atlas、VirtualAPK、DynamicAPK。\n - APP 小程序。即功能以小程序的运行在容器化，即可以像 Web 容器一样实现远程更新，还能有效地控制开发商的权限，培养自己的生态。\n\n尽管让人们下载 APP 的成本越来越高，APP 平台化成为了一种趋势。\n\n哪怕 APP 的原生仍占很重要的一部分，但是 App 平台的方案 + 应用插件化模式的生态构建，也是云研发要考虑的重要因素。\n\n#### 前端：微前端与应用组件化\n\n今年是微前端开始火爆的一年，微前端框架层出不穷：SingleSPA、Mooa、qiankun、ngx-planet，还有诸如于《前端架构：从入门到微前端》这样的书籍。它让越来越多的企业开始思考前端架构的未来，也完善丰富的微前端相关的基础设施。从某种意义上来说，这是组件化的一种方式，只是原先的组件只是简单的 UI 组件，而现在的组件是一个完整功能的应用。只需要设计好对应的 pipe，就能完成一个应用的开发。\n\n而随着 5G 的到来，微 “服务化” 前端应用、Web Component 的体积已经变得让人可以接受。进行功能编排，将成为云研发的一个重要组成——毕竟，插件市场地不断火爆，可以看出一些端倪。\n\n### 代码化\n\n对于这部分的一句话总结是：\n\n - Given Future[Dev]\n - When Everything as Code，\n - Then you can Guard\n - Then you can Refactoring or Rewrite it.\n\n然后，以下大概就是三种完全不同的模式。\n\n#### 设计到代码：填空式开发\n\n起先我只有两种模式，直到月初在公司内部听到了相关的分享，Get 了第三种模式：面向于大型组织的类型流 (https://github.com/notyy/TypeFlow) 开发。\n\n这种方式颇为适合大型组织的软件开发模式，由高级工程师设计出基本的模型与软件架构，生成对应的方法名称，以及其所需要的返回结果。这种模式事实上在过去已经有了，剩下的就是普通的开发人员去填充对应的代码。再结合 Serverless 等基础设施，便可以直接集成上线。\n\n它表面上看它是设计生成的代码，实则设计即代码。\n\n#### 需求到上线：无代码编程\n \n年初，我写下了那篇《[无代码编程](https://www.phodal.com/blog/low-code-programming/)》，通过这篇文章，我结交了更多无代码/低代码已经有大量的案例表明，这是一种可行的开发模式。\n\n无代码编程的本质是业务模式 + 编程模式的抽象化，以领域特定的场景解决领域特定的问题。所以，低代码编程 / 无代码编程它只能解决领域特定、简单场景的需求，无法解决大部分的问题。\n\n无代码编程做了一件了解不起的事情是，直接对于业务和设计即需求的抽象，实现了直接由需求到代码的直达。\n\n#### 代码化：DSL as DSL\n\nDSL 即 DSL，即把每件事物都变成 DSL。考虑到我正在编写一篇关于 DSL 如何设计的文章，我就不展开详细的讨论：\n\n0. 汲取领域名词\n1. 模型分析与抽象\n2. 模型行为抽象\n3. 寻找关键抽象\n4. 场景代入\n5. 实现 DSL\n6. 迭代优化\n\n而代码本身也应该是一种 DSL，才能进一步完成云平台的建议。需求、设计、代码、构建、部署、运营都应该抽象成 DSL，才能完成真正意义上的云平台。\n\n### 协作设计文化\n\n软件开发是一个集体行为，软件设计也是一个集体行为。所以，一个好的云研发平台应该要**融入共同协作的基因**。\n\n#### 软件开发文化\n\n采用了敏捷，却始终敏捷不起来，有一部分的原因在于：部门墙。对于非互联网公司来说（对于大部分互联网公司也是如此），开发一个软件往往需要在多个部门甩锅：业务部门、技术部门、测试部门、市场部门……。\n\n#### 业务（领域）驱动设计\n\n以我多年的读书经验来看，人们采用开发出失败软件的原因，无非就是两点：『**缺少协作设计**』和『**知识传递**』。对了，还有技术水平不行，这个反而不是那么重要。\n\n而 DDD （领域驱动设计）和事件风暴，正是软件开发文化的一种实践，通过协作设计的方式，传递知识，以妥协出符合大家需要的应用。\n\n#### 服务端服务中台与客户端组件中台\n\n可能是我对于中台的误解，我习惯性称中台为『**不可清空的垃圾回收站**』。但是，它做了一件不可思议的事件，将 “基础设施服务” 化，成为了一个 common 的 common 的 common。好了，调侃到此结束。\n\n随着中台建设的进一步完善，大量的基础设施，将从原先的各个业务部分，统一到了这个 ~~垃圾回收站~~ 大平台。\n\n有了这个基础部分，我们才能迈向下一步。\n\n## 引子 2：编程的本质\n\n![编程的本质](images/cynfin.jpg)\n\n好了，我要继续瞎扯了，首先再次回答那个问题，如何以更高效地方式进行软件开发？ 那么，首先我们需要找到一个解决方案，以应对那个问题：如何解决人类智商不够的问题？\n\n### 解决复杂问题\n\n于是，首先，让我们引入 Cynefin 框架来解决复杂问题。\n\nPS：复制和粘贴大法好啊，一时爽一直爽\n\n\u003e  **简单（Simple）**，该域中的因果关系显而易见，方法是感知——分类——响应（Sense - Categorise - Respond），我们能够应用最佳实践。\n\n\u003e **繁杂（Complicated）**，该域中的因果关系需要分析，或者需要一些其他形式的调查和 / 或专业知识的应用，方法是感知——分析——响应（Sense - Analyze - Respond ），我们能够应用好的实践。\n\n\u003e **复杂（Complex）**，该域中的因果关系仅能够从回想中感应，不能提前，方法是探索——感知——响应（Probe - Sense - Respond ），我们能够感知涌现实践（emergent practice）。\n\n\u003e **混沌（Chaotic）**，该域中没有系统级别的因果关系，方法是行动——感知——响应（Act - Sense - Respond ），我们能够发现新颖的实践（novel practice）。\n\n\u003e  第 5 个域是失序，该域中不清楚存在什么样的因果关系，这种状态下人们将会恢复到自己舒服的域做决定。Cynefin 框架拥有子域，简单和混乱之间的一线之隔是灾难性的：骄傲自满导致失败。\n\n有了这个框架之后，我们便来到了第一个结论。对于编程来说，我们的关键性问题在于：**如何将复杂问题繁杂化？**。因为简单的问题便简单，繁杂的问题也容易解决。\n\n### 复杂问题的应对之道 \n\n什么是复杂问题？\n\n引用公司大佬的三句话：\n\n1. 场景多且复杂\n2. 人类的智商不够\n3. 语言不统一\n\n这三个问题的答案暂不免费公开，有意者可以咨询我 —— 其实都在本文里。\n\n看完文章后，回过头来回顾一下这个问题。\n\n### 大型组织的软件开发模式\n\n为了解决上述的问题，对于大型组织来说，采用的第一个模式就是：拆解。\n\n - 资深开发人员，设计架构\n - 中级开发人员，review 代码\n - 普通开发人员，完成开发 \n - 新手开发人员，写写测试\n\n而就当前而言，这几个部分存在一些割裂。代码反应架构，架构实现代码。缺少相应的架构守护、质量门禁等等，并且诸如于 review 的工作是由机器完成的。\n\n## 云研发\n\n好了，看到这里不容易。因为剩下的内容已经不重要了。\n\n### 什么是云研发？\n\n再一次地，让我们看一下定义：\n\n\u003e 云研发，是一种生于云上的**闭环** + **代码化**的软件开发方式。它可以让业务人员、开发人员、运营人员等在同一个云端**共同协作**、**透明化**地完成整个软件的生命周期（需求、设计、编码、构建、部署、运营），而非相互隔离，又或者是借助于多个软件才能完成工作。\n\n于是乎，它不同于云主机 / 远程主机开发模式，只需要一个浏览器 / 客户端  / IDE，便可以在线完成：\n\n  - 实例化需求\n  - 架构、交互的设计\n  - 编码的代码化\n  - 自动集成与构建\n  - 无环境部署\n  - 人工智能运营\n\n举起我的炒板栗：\n\n1. （调试）输入一个 `console.log` 或者  `fmt.Println` 便可以在生产环境对应地打出日志。\n2. （需求直接上线）改一个 Icon 的需求，在图标上传到 Kanban 的时候。NLP 后，自动提交到代码库，部署到生产环境。\n3. （代码创建需求）把默认字体的色彩，由 #000 改成 #384452 的时候，能反触发对应的需求变更——不过就是 commit message，反向地创建需求嘛。\n4. （设计同步）模型上添加一个新的字段，对应的完成前端、后端模型的自动化更新。\n5. （代码构建同步）新的分支，新的 pipeline，用完即删。\n6. ……\n\n它基于这么一些原则：\n\n1. 代码化优于过程化数据。\n2. 流程自闭环优于交互。\n3. 度量内建优于可视化。\n\n要的就是这么简单，对于开发来说，只是对应于领域建模、详细设计、填空式开发等。\n\n##  如何构建云研发平台\n\n### 成熟度模型\n\n就定义来说，我们可以将其划分为五个阶段：\n\n1. 具备基本的远程编程能力及自动化部署。即代码无需在本地\n2. 在云端能完成软件开发的完整生命周期。能在云端完成所有的软件开发的工作，并且配套\n3. 云研发平台上的云研发平台。（自举）\n4. 借助于代码化的方式，将软件开发的每一个步骤都变成代码\n5. 实现开发全流程的自动优化。如自动化的蓝绿部署，自动化选择方案，自动化优化。\n6. 无人编程。Human Over\n\n第一个阶段。靠人海战术就可以实现了。\n\n第二个阶段。依赖于抽象软件开发模式。\n\n第三个阶段。证明自己，体力劳动。\n\n第四个阶段。进一步抽象软件开发。\n\n第五个阶段。抽象人工部分，智能完成。\n\n所以，嗯，大概要 N 的时间才能完成这个系统的设计。毕竟，云研发是一个复杂问题，我们需要不断拆解系统，结合微架构、代码化、协作设计三个核心要素，以免我们在历史的长河中消失。\n\n### 云研发平台基石\n\n虽然，我一直在强调实现只是一个细节，但是还是得大致了解一下实现机制。\n\n#### 集成开发环境\n\n编码环境 + 设计环境。\n\n微信小程序、支付宝小程序、在线 Web IDE，VS Code / Monaco Editor 几乎已经当前成为了定制编辑器 / IDE 的最好选择。这样一看，JetBrains 再不努力，可能会失去未来，就像当年的 Delphi 一样，笑~。\n\n这方面的技术在业内已经相当成熟了，不就是加一些插件嘛。\n\n不过呢，它们只是在堆砌一些功能，缺乏闭环上的设计：\n\n1. 需求关联设计，关联代码 \n2. 代码展示设计，关联需求\n3. 构建关联代码，连接部署\n\n如你所知的提交信息规范是一种形式，它可以关联到需求；如你所知的领域建模是一种形式，让代码关联到设计上；\n\n#### 基础设施\n\n尽管，在文章开头的时候，我说了基础设施不重要。但是到真正需要实施的时候，我们不得不强调它的重要性。我们需要的东西有：\n\n - **微架构支持**\n - **部署和构建支持**\n - **自动配置化管理**\n - ……\n\n而围绕在它背后的是各种模式的提炼。\n\n#### 模式提炼\n\n无论是在哪个行业，值钱的东西在于**原则与模式**。原则与模式是用来快速提升能力的方式，换句话来说，就是让新手能像以大牛一样的方式工作——尽管会烂用模式。所以：\n\n - **代码的模式类库**\n - **开发流程模式**\n - **用户体验设计模式**\n - ……\n\n这些是核心所在，抽象、提取、模式化。\n\n#### 全流程闭环\n\n如你所猜想的一样，构建这样一个平台的难点，不在于实现功能，而在于设计。只需要保证在当前阶段的信息，能够传递到下一阶段即可，而不在于你使用什么工具。\n\n你可以使用 Jira、Trello、Mingle 或者基于 Git + DSL 的方式，只需要保证它们能关联到下一阶段，即可。一步步往下，将信息关联到设计、代码、构建、部署、运营，运营再反应到需求上，就能完成上的设计。\n\nSo？\n\n## 原型设计与关键因子\n\n作为模式的拆解，我做了一个简单的分级，以便于一步步实现整个系统：\n\n![原型设计与关键因子](images/levels.jpg)\n\n### 需求\n\n事实上，采用诸如 Cucumber 一样的 Given-When-Then 三段式设计就够了。所以在我的 story 工具里，利用了注释作为额外的信息扩充。Cucumber 使用的 DSL 已经有丰富的\n\n```\n# id: OGr9CObWR\n# startDate: 2019-11-21T23:44:27Z\n# endDate: 2019-11-21T23:44:27Z\n# priority: \n# status: \n# author: \n# title: add executable bin file\n# language: zh-CN\n@math\n功能:add executable bin file\n\n  场景:\n    假设:\n    当:\n    并且:\n    那么:\n```\n\n有了这个设计，我们可以将这个设计结合到我们的下一步设计中。\n\n### 设计\n\n其实 UML 本身也是一个不错的原型，只需要创建一个 DSL 将其中的一部分转成 UML，再结合一下 UI 上的 DSL 便能实现流程上的设计：\n\n```\nflow login {\n    SEE HomePage\n    DO [Click] \"Login\".Button\n        REACT Success: SHOW \"Login Success\".Toast with ANIMATE(bounce)\n        REACT Failure: SHOW \"Login Failure\".Dialog\n\n    SEE \"Login Failure\".Dialog\n    DO [Click] \"ForgotPassword\".Button\n        REACT: GOTO ForgotPasswordPage\n\n    SEE ForgotPasswordPage\n    DO [Click] \"RESET PASSWORD\".Button\n        REACT: SHOW \"Please Check Email\".Message\n}\n```\n\n最近，我们在做一个对应的架构设计平台：\n\n![Entrope](images/entrope.jpg)\n\n结合我的 [https://github.com/phodal/design](https://github.com/phodal/design) 用于代码生成设计，设计转为代码。\n\n### 代码\n\n代码生成并不是一件新鲜的事物，有大量的人在做大量的事件。编写一个 DSL，用这个 DSL 结合编程语言描述 DSL 来生成不同的编程语言，这便是我最近在做的事情之一。它并不复杂，只是繁琐。\n\n嗯，我花了很多时间在设计这个步骤的两个 DSL，其中一个是生成语言的 DSL，一个则是独立的编程 DSL。\n\n与此同时，对于代码来说，我们关注于：验收标准和适应度函数。\n\n**验收标准**：\n\n - 设计生成代码，代码反应设计\n - DSL 生成代码\n\n**适应度函数**\n\n - 软件质量门槛\n - 自动化架构守护\n - 自动化测试生成（回录）\n - 系统演进设计\n\n借助于此，我们才能承上启下。\n\n### 构建\n\n对于持续集成来说，需要手动去配置是一个糟糕的事情。所以，我们 Jenkins 使用了 Pipeline as Code 来抽象流水线的构建。但是，它没有真正解决问题，因为现实的软件开发是非常复杂的。对于一个项目来说，它存在过多的分支，不同的构建。所以，真正意义上的持续构建，应该采用诸如于 Pipeline as Pipeline 这样的方式。\n\n### 部署\n\n事实上，DevOps 技术已经足够的成熟，我们已经能实施相关的步骤：\n\n1. 部署自动化\n2. 部署代码化\n3. 提交即上线\n4. 部署自治\n\n代码质量的控制，自动化测试，决定了部署成熟度。\n\n### 运营\n\n这一步，我还不是非常擅长，以我有限的经验来看，现有的工具就够了。唯一要做的事情是，收集数据，抽象模式，构建 DSL，串联起来。\n\n1. 运营可视化\n2. 运营中心化\n3. 代码化运营\n4. 运营需求化\n\n需求 -\u003e 代码 -\u003e 运营，运营反馈需求。\n\n## 云研发平台成熟度模型\n\n嗯，看标题就够了。\n\n### Level 1：可追述、电子化\n\n### Level 2：全流程闭环\n\n### Level 3：云平台上的云平台\n\n### Level 4：代码化云平台\n\n### Level 5：自动化优化流程\n\n## level 6：human over\n\n哦，对了，做平台是一件苦逼的事情。\n\n引用：\n\n - Cynefin 框架部分：https://www.infoq.cn/article/2013/10/cynefin-framework-playing-lego\n - GitHub 上的类型流： https://github.com/notyy/TypeFlow\n - 无代码编程：https://www.phodal.com/blog/low-code-programming/\n - 微前端如何落地：https://www.infoq.cn/article/xm_AaiOTXmLpPgWvX9y9\n\n云研发 IDE —— Uncode\n\n在先前的一系列《[云研发：研发即代码](https://github.com/phodal/cloud-dev)》文章里，我们介绍了软件工程的代码化闭环。同时，在《[Water：云研发架构模式](https://github.com/phodal/water/)》介绍了设计这样的开发环境里，我们所需要的一些模式。今天呢，作为这一系列的落地实践，我们将介绍**云研发 IDE**的设计思想，以及如何实现，当然还有一点儿早期代码：[https://github.com/inherd/uncode](https://github.com/inherd/uncode)。\n\n第一次声明：这是一个概念性 IDE 的设计，暂不适合任何生产环境。\n\n在开始真正阅读之前呢，为了能更好地让大家理解，我们要回顾一下软件工程行业：\n\n - **DevOps 理念**在国内的软件行业有了长足的发展，在包括传统企业（银行、制造业）在内的公司里已经广泛接受，并进行了大规模推广。\n - **云原生技术**已经成为市场的主流趋势。云迁移与遗留系统上云是市场的一大热门话题。\n - **中台方法论**在实践上还缺少真正的成功案例。\n - **低代码/无代码平台**逐渐成为新的建设目标。\n - **云开发**有了越来越多的中小规模应用案例。\n - **AI 生成代码**正在被小范围验证。\n\n从整个行业而言，人们的关注点一直是**如何提升技术生产力？** 现在技术到了一个新的阶段了，而需求的转换大大限制了人们的开发速度。于是无论我们的 DevOps 和云开发实施得再好，也会陷入需求与技术隔离的瓶颈。这就是为什么我们需要[云研发](https://github.com/phodal/cloud-dev) 理论体系 :)，通过代码化的方式，一站式解决需求到设计，再到代码的问题。\n\n对于云研发理论来说，我已经设计好了理论基础、软件架构、开发模式，并且对其中的一系列东西进行了验证，如：[文档代码化](https://www.phodal.com/blog/document-as-code/)、[需求代码化](https://www.phodal.com/blog/requirement-as-code/)、[代码的代码化](https://www.phodal.com/blog/charj-lang/) 等。\n\n我们需要一个容器，把这些内容、模式、代码整合到一起，这就是 Uncode，一个概念性的云研发 IDE。\n\n# Uncode，一个云研发 IDE\n\nUncode 是一个面向云研发时代设计的下一代概念性 IDE。特性：\n\n - 流程化为领域语言。Process as code\n - 一切皆 DSL。万物代码化\n - 填空式/选择式编程。\n - 开发环境即流程。\n\n简单来说，你可以在这个 IDE 上完成：需求的编写，转换需求为设计，设计关联代码，禅模式编程，开发完即可上线。\n\n与之相对比的是，传统的一站式 DevOps 门户，尽管你可以通过跳转来完成，但是无法相互关联和设计。与之相近的是 GitOps，即将应用系统的声明性基础架构和应用程序存放在 Git 版本库中。但是它们都不闭环，也不完整。\n\n## 云研发 IDE 模式：流程即领域语言\n\n回到软件开发上，我们的软件开发需求始于一个大特性或者史诗故事，这些故事会转换为一个 `feature`，如 Cucumber 中的：\n\n```gherkin\n# author: Phodal HUANG\n# status: doing\n# language: zh-CN\n功能: 第一个用户故事\n\n  场景打开 Uncode\n  假如我在 Terminal 工具里\n  当输入 uncode\n  那么则能在 Uncode IDE 里打开当前项目\n```\n\n需求设计人员在这一步之前，将需求转换为了故事，故事与特性之间的关系记录在这个 `feature` 中。开发人员从 IDE 中看到需求，标记了对应的状态 `status`，就可以进入代码的设计阶段。\n\n在设计这个阶段，我们先设计了 `design` 的三种类型：`flow`、`model`、`ui`，对应于流设计、模型设计和 UI 设计。而我们要在 Uncode 中实现的部分便是需求与模型、流和 UI 的绑定。围绕模型，我们还得构造统一的领域语言，用于自动化关联接口与设计。从模式上来说，这个和无代码/低代码的开发是相似的。\n\n唯一不同的是描述方式。使用领域特定语言来描述内容，我们才能对系统进行合理地重构。\n\n## 云研发 IDE 模式：一切皆文件\n\n\u003e Linux/Unix下的哲学核心思想是『一切皆文件』。\n\n在现今的开发环境之下，我们在看板上挑选卡片，又或者是通过低代码编辑器生成，使用的存储介质都是数据库。而数据库这些东西并不存在于开发环境中，而是放置于远程服务器上。这就造成了另外一个痛点，无法简单反向关联、需求与代码隔离等等。\n\n于是，作为云研发 IDE 的第二个模式，将所有的内容使用文件保存，并且使用版本管理工具（如 Git）进行管理。如我们的需求以类似于代码的形势存储在数据库中，可以实现以下特性：\n\n - “不可伪造”\n - “全程留痕”\n - “可以追溯”\n - “公开透明”\n - “集体维护”\n\n没错，这就是一个区块链系统。一旦需求发生了变化 ，你可以即刻感知到。不过，一旦你的代码与模型不相符合，你的代码就无法提交，或者模型被自动修改 :(。\n\n## 云研发 IDE 模式：开发环境即流程\n\n作为一个集成开发环境，现有的 **一站式 DevOps 软件研发管理协作平台** 都应该只被当作管理和展示用途。而从设计本身来说，一个 Dashboard 和一个开源工具，本身就分工。\n\n我们在代码库上有了需求，那么我们可以借助于 IDE：\n\n1. 将需求以看板的形式在本地重新可视化出来。\n2. 将设计领域的语言在本地可视化出来，并将之与代码进行关联。\n3. 高亮需要所有修改的代码块。如 Controller、View 等。\n4. 将模型的修改反向关联到设计上，以实时追踪设计的正确性。\n\n我们还可以做一些不那么正确的事情 ，如锁定开发人员的修改范围。\n\n## 云研发 IDE 模式：填空式/选择式编程\n\n对于软件架构师来说，人们经常有这么一些痛点：\n\n - 面对的是缺乏经验的开发者，难以快速地推进系统的开发。\n - 开发者缺乏对系统的了解，在错误的地方修改错误的代码。\n\n因此，回到 [TypeFlow](https://github.com/notyy/TypeFlow) 的观点上，我们既然已经设计好了模型，设计好了输入和输出，那么我们一定能生成中间的方法及其返回值，并为其设计一个 mock 的对象。如：\n\n```java\n@RequestMapping(\"/\")\nString home() {\n\t\treturn \"Hello, World!\"\n}\n```\n\n这种模式对于业务应用开发来说，非常易于实现 —— 生成绑定过程中的各类函数等等。\n\n**选择式编程**。而一旦我们在组织内的所有代码都被索引之外，我们有能力通过识别输入和输出，以及对应的方法名，就能在 IDE 中推荐对应的方法让你选择。\n\n## 云研发 IDE 基础要素\n\n就这么一看，我们只需要搞好 IDE 的事情即可。然而， 并非如此，我们还要做的事情还有一些：\n\n1. 开发即部署。即 local dev 便是 dev server，可直接接入现有的系统。\n2. 万物即 DSL。具备一定等级的程序语言设计能力。\n3. API 的 API。即将现有的内部、外部 API 进行抽象化设计，以提供快速可用的 API。\n\n### 开发即部署 —— 云开发环境\n\n从开发层面来看，我们一直在往复地浪费本地环境和线上开发环境，与此同时还有对应的测试运行时间、构建时间等。我们需要一个于**云开发环境**的机制。\n\n**加速联调、测试过程**。当我们的本地环境上云之后，一旦需要与其它系统对接时，所有的开发、测试效率将大大提升。譬如说，我们的接口需要多提供一个参数，传统模式之后，我们要在本地运行，再通过流水线构建和部署。而现在，不再需要这个过程了，只需要配置好 Gateway，轻轻松松进行开发。\n\n**加速环境搭建**。我们不再需要在本地配置开发环境，只需要 1-click 就可以在本地 IDE 里直接调试。\n\n市面上已经有一个勉强配合的概念：[Nocalhost](https://github.com/nocalhost/nocalhost)\n\n### 抽象的抽象：DSL\n\n对于需求、设计、开发、测试等的抽象，一直是我在去年研究的重点，它包含了：\n\n - 需求的抽象\n - 设计化为抽象\n      - 架构描述语言\n      - 统一建模语言\n - 版本管理抽象\n - 构建工具抽象\n\n即将这一系列的步骤转换为领域特定语言 —— 只有将流程、工具、行为进行抽象，我们才得以优化整个系统。\n\n## 胶水设计：API 的 API\n\n软件开发是一项复杂的团队活动。在一个系统里，我们要与大量的内、外部系统进行关联。而为了简化开发人员的负担，我们需要提供一个新的 API 来将现有的 API 进行封装。\n\n如在现有的模式之下，为了记录一个日志，我们需要在依赖管理工具中引入对应的依赖，再添加相当的代码。而所有的 API 都是在更新的，这一系列应该将由 IDE 本身来完成。在这种模式之下，我们只需要输入对应的 `snippets`，便能完成这一系列的自动化过程操作。\n\n## 技术细节\n\n最后，我们还是回到代码上：[https://github.com/inherd/uncode/](https://github.com/inherd/uncode/)\n\n### 架构设计\n\n我决定使用我设计的新架构设计套路来展示一上 Uncode IDE 的架构。由于不确定性较大，现有的系统是一种介于单体与微架构 + 模块化的方式设计的，我想了想后来就称之为**流体模式**。一种在持续演进的过程中，不断进行不可预料地拆分架构单元的模式。\n\n在驱动方式上，由四种模式构成：\n\n - 模块化。\n - 管理和过滤器。主要进行领域特定语言的设计\n - 搭档模式（sidecar）。将诸如语言解析等独立为进程，通过进程调用来实现跨平台\n - 容器桥。将 UI 展示与逻辑相隔离，让 IDE 的大部分组件与 UI 无关。\n\n同时系统的物理设计上，打算采用**领域驱动**的方式进行。\n\n### 框架选型\n\n考虑到这是底层开发 + 系统编程，我们：\n\n1. **使用 Rust 来作为主要开发语言**\n2. 在 UI 展示上，暂时使用 Tauri（WebView 容器） + React 来展示需求（本地看板）与设计（建模等）。\n3. 使用 TypeScript 作为 UI 部分开发语言\n4. 使用 RPC 作为与多个 DSL 的通信协议\n5. ……\n\n依旧地，这个项目将继续在 Inherd 小组上开发~~。\n\n## FAQ 及其它\n\n代码：[https://github.com/inherd/uncode/](https://github.com/inherd/uncode/)\n\n### vs Intellij IDEA or VSCode / Theia\n\n并非完全竞争关系，编码这部分的功能，还是这两货比较流行。Uncode 不会在前期造这方面的轮子，只是显式地集成它们，或者被集成。\n\nUncode 优先解决 DevOps 的本地化，将其融入开发的开发过程的问题。\n\n### 其它\n\n最后一次声明：这是一个概念性 IDE 的设计，暂不适合任何生产环境。\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fphodal%2Fcloud-dev","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fphodal%2Fcloud-dev","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fphodal%2Fcloud-dev/lists"}