以再生优先的开发，让应用安全变更

为什么修补式变更会变成技术债务

修补式是指当出现新需求时，用最小代价把它塞进应用。它看起来很快，因为确实很快。问题在于每一次修补都是局部修复，而局部修复很少符合应用应有的结构。

随着时间推移，修补会堆积。应用仍能运行，但代码和配置开始互相矛盾：数据库表明一回事，UI 暗示另一种，真正的规则散落在三个不同的地方。那种不匹配就是技术债务。这不仅仅是“糟糕的代码”。它是对下一次变更不断增加的成本。

你通常能发现它的征兆：

• 逻辑变得纠缠，一个小规则改动会影响许多界面或端点。
• 字段被重复（“status”、“ticket_status”、“status_v2”），因为重命名看起来有风险。
• UI 变得脆弱，隐含依赖于特定的数据结构或边缘情形。
• 权宜之计变成永远存在的“临时”标志。
• 修复需要后续修复，因为没人确定还会破坏什么。

最痛苦的是风险增长的速度。一处本应很小的变更（增加审批步骤、调整定价规则、把一个用户角色拆成两个）会变成有风险的发布，因为你无法预测冲击范围。测试变成猜测。回滚变难，因为补丁触及了不相关的部分。

再生优先开发就是为了解决这个问题。目标是把应用结构成可预测且可逆的方式，让平台能在不带走昨日那些补丁技巧的前提下再生成干净的代码。

一个实际目标包括：

• 一个清晰的数据真实来源（没有重复的“几乎相同”的字段）。
• 规则集中在一个地方，而不是散落在 UI 与端点之间。
• UI 专注于展示和输入，而不是业务决策。
• 在模型和逻辑中做变更，然后再生成，而不是手工编辑产出。

像 AppMaster 这样的平臺支持这种方式，因为应用由模型和可视逻辑定义，平台再生成完整的源代码。再生成只有在你避免补丁驱动的结构时才会保持干净。

再生优先开发意味着什么

再生优先开发把你的应用视为一组清晰的模型，而不是一堆手工编辑的代码。你修改模型，再生成，就能得到一个新鲜、一致的应用版本。关键是发布变更时不留下让下一次变更更难的额外技巧。

在补丁优先的工作流中，一个小需求（新增状态字段、审批步骤）会被放在最容易改动的地方。有人修改一个 API 处理器，更新一个界面，在别处加入一个特殊分支，然后继续向前。今天应用能工作，但逻辑已经四散。经过几轮之后，没人确定真实规则在哪里。

采用再生优先后，真实来源保持在模型里：

• 数据模型：实体、字段、关系、约束
• 业务逻辑模型：决定发生什么的规则与流
• UI 模型：屏幕、组件以及它们如何绑定数据

从这些模型生成的一切（API 端点、数据库访问、Web 与移动端代码）都是“产出”，而不是可以随便快速修补的地方。

在 AppMaster 中，这些产出可以包括后端的 Go、Web 的 Vue3，以及移动端的 Kotlin 或 SwiftUI。当需求改变时，你只需在模型中更新一次并再生成，而不是在多个文件中到处寻找同一条规则。

这可以让应用在各层保持一致，因为相同的定义驱动每一部分。如果“Ticket Status”变为必填，数据库模式、验证、API 与 UI 绑定应该同步更新。如果审批规则改变，你更新流程，所有端点与界面都会反映同样的逻辑。

思维方式的转变很简单：编辑你真正想改的（模型），生成你需要的（代码）。

构建可演进的数据模型

要让再生优先开发起作用，就从最少变动的部分开始：数据模型。支持变更的应用能应对功能请求，并不是因为每个界面都完美，而是因为核心实体稳定且命名清晰。

从业务在一年后仍会使用的名词开始。对许多应用来说，这意味着 User、Account、Team、Ticket、Order、Invoice、Product 或 Message。当这些概念清楚后，其他一切（工作流、权限、UI）都有了坚实基础。

命名不是小事。它能防止以后变更演变为令人困惑的迁移和破碎的逻辑。选用单数实体名，字段命名保持一致（created_at 而不是 createdAt），并选择贴近现实的类型（货币用 decimal，带时区的时间戳并约定好规则）。小的不一致会蔓延到规则、过滤器和报表中。

为增长做规划，但不要过度设计。你不需要预测每个将来字段，但可以让常见的变更更安全：

• 优先使用能接受新增值的状态字段，而不是为每个阶段新增一张表。
• 对不是总有的数据使用可选字段（phone_number、external_id）。
• 及早加入审计字段（created_at、updated_at、created_by），以免后来补齐造成复杂性。
• 把“notes”和“metadata”与核心字段分离，避免实验性数据污染主模型。

可视化的数据设计器很有帮助，因为你能在成为代码之前看到关系和约束。在 AppMaster 中，Data Designer 会把你的模式映射到 PostgreSQL，这样你可以在一个地方建模表、字段与链接，并在需求变化时再生成干净的源代码。

示例：一个支持门户最初将 Tickets 关联到 Accounts 和 Users。后来业务要求添加优先级、类别，以及一个名为“Waiting on Customer”的新状态。如果 Tickets 已有状态字段和用于详情的可选字段，你就可以添值和字段而无需重新设计数据库。再生成的应用会保持查询与 API 的一致，你也避免了一堆一次性修补。

目标是今天可读、明天更宽容。

让业务逻辑模块化且易读

业务逻辑通常是变更导致破坏的地方。一个“临时起作用”的快速修复今天看似可行，明天就会变成一张特殊情况的网络。采用再生优先开发，你需要把逻辑设计成能够被干净再生成的形式，而不是依赖只存在于某人脑中的补丁。

一个实用方法是把每个工作流视为一组小模块。每个模块只做一件事：校验输入、计算价格、决定路由、发送消息、更新记录。在 AppMaster 中，这自然对应于 Business Process Editor。较小的流程更容易阅读、测试、复用与替换。

以输入与输出思考

在构建模块前，把两件事写下来：它需要什么，以及返回什么。如果你无法用一句话描述，说明这个模块可能做得太多。

好的模块边界清晰。它们接受明确的输入（用户角色、工单状态、订单总额），并返回明确的输出（批准或拒绝、最终价格、下一步）。这种清晰度让变更更安全，因为你可以替换某个模块而不必猜测它还影响了什么。

一个快速检查表：

• 每个模块只做一件事（校验或计算或路由）
• 输入作为参数传入，而不是“到处找”
• 输出被返回，而不是藏在副作用中
• 名称描述结果（例如 ValidateRefundRequest）
• 错误一致处理

避免隐藏依赖

隐藏的依赖让逻辑脆弱。如果工作流依赖全局标志、无声的状态变更，或“某个变量之前已经被设置”，小改动就可能以你意想不到的方式改变行为。

有意地在流程中传递状态。如果必须存储某些东西，就把它存放在明显的地方（比如数据库字段）并显式读取。避免“魔法”行为，比如在一步中更改记录却假定另一部会自动察觉。

把决策点可视化。例如，一个支持门户可能在“是否 VIP 客户？”和“是否在工作时间外？”上分支。如果这些分支清晰并有标签，未来像“VIP 规则在周末改变”这样的改动就是一次快速编辑，而不是冒险的重写。

把 UI 的关注点与规则和数据分离

一个易变更的应用在再生成时最好是 UI 保持“哑”式。屏幕应该收集输入、显示状态并引导用户。当业务决策隐藏在按钮、校验和一次性界面逻辑中时，每一个新需求都会变成补丁。

把 UI 当作共享规则与数据之上的薄层。然后平台可以干净地重建呈现层，而不必在十几个地方重复实现决策。

UI 在哪里结束、业务规则在哪里开始

一个实用的划分是：UI 负责清晰性；业务逻辑负责真相。UI 可以格式化、标注并帮助用户。业务逻辑决定什么被允许以及接下来发生什么。

UI 的职责通常包括：

• 展示数据并收集用户输入
• 格式化（日期、货币、电话掩码）
• 基本必填检查（空与非空）
• 以普通语言展示逻辑返回的错误
• 导航与布局

业务规则应放在屏幕之外，例如在工作流或流程编辑器中："refund requires manager approval"（退款需要经理审批）、"VIP customers skip the queue"（VIP 客户跳过队列）、"ticket cannot be closed without a resolution code"（工单在无解决码时不能关闭）。把这些规则绑定到数据模型，而不是特定页面。

设计一次，跨 Web 与移动复用

如果你支持多个客户端（Web 加原生移动），重复会导致漂移。为常见模式复用共享组件（工单状态徽章、优先级选择器、客户卡片），但通过让它们使用相同的数据和规则结果来保持行为一致。

例如，你可以在数据设计器中建模工单状态，通过单一业务流程驱动状态变化，让 Web 和移动 UI 都调用该流程并渲染返回的状态。当“Escalated”变为“Urgent review”时，你只需更新一次并再生成，而不是在每个屏幕中寻找隐藏条件。

一个好测试是：如果你把某个屏幕删除并明天重建，应用是否仍能执行相同的规则？如果能，说明分离有效。

逐步操作：为干净再生成搭建应用结构

当你的应用被清晰分成可独立变更的部分时，再生优先开发最有效。先以模块思考，而不是以屏幕思考。

给核心模块命名并在脑中与工作中保持分离：数据（表与关系）、流程（逻辑）、API（端点）、Web UI、移动 UI。出现需求变更时，你应该能指出哪些会变更，哪些应保持不动。

一种保持易变更的构建顺序

使用小循环并把每一步控制在有限范围内：

1. 先建模数据：与现实相符的实体、字段与关系。
2. 添加可复用的业务流程。让每个流程只做一件事（Create Ticket、Assign Agent、Close Ticket）。
3. 在逻辑可读后，把流程连接到 API 端点。把端点当作流程的包装器，而不是隐藏规则的地方。
4. 围绕用户任务构建 UI 屏幕，而不是直接围绕数据库表。
5. 每次小改动后再生成并测试。

小例子：在不凌乱打补丁的情况下应对需求变化

假设你在 AppMaster 中构建一个支持门户。最初只有 Tickets 与 Comments。一个星期后，业务要求添加 Priority，并且新增规则：VIP 客户默认高优先级。

在模块化结构下，你只需修改数据模型（添加 Priority），更新一个业务流程（Create Ticket 根据客户类型设置 Priority），再生成并验证同样的 UI 任务仍然可用。无需在多个屏幕间四处修补。

一个简单习惯有帮助：每次再生成后，快速运行关键流程的端到端测试（创建、更新、权限检查），然后再加入下一个功能。

示例：一个不断演进的客户支持门户

想象一个小型支持门户。客户登录、查看工单、打开工单查看详情并添加回复。支持人员看到相同工单并能添加内部备注。

再生优先方法把三样东西分离开：工单数据模型、业务流程（工单如何流转）、以及 UI 屏幕。当这些部分清晰时，你可以只改动一部分而不用在别处打补丁。

从简单开始，但为变更做结构化设计

初始版本可以很精简：

• 数据：Users、Tickets、Messages
• 流程：Create ticket、Reply、Assign to agent
• UI：Ticket 列表、Ticket 详情、新建工单表单

在 AppMaster 中，这可以映射到基于 PostgreSQL 的数据模型（Data Designer）、拖拽式规则工作流（Business Process Editor），以及分离的 Web 与移动 UI 构建器。

变更 1：添加优先级与 SLA 日期

产品要求 Priority（Low、Normal、High）和 SLA 到期日。采用再生优先结构，你在 Ticket 模型中添加字段，然后只更新读取或写入这些字段的地方：创建工单流程设置默认优先级，客服界面显示 SLA 到期日，列表界面新增过滤器。

平台再生成后，后端和 API 会把新字段作为一等公民，代码中一致体现这些字段。

变更 2：关闭前增加审批步骤

现在关闭工单需要特定客户的经理审批。你不要把关闭规则散落在多个界面，而是在模型中新增明确状态（Open、Pending approval、Closed）并更新关闭流程：

• 客服请求关闭
• 系统检查是否需要审批
• 经理批准或拒绝
• 只有审批通过后工单才关闭

因为规则在单一流程中，UI 只需展示当前状态与允许的下一步。

变更 3：移动端推送通知

最后，用户希望在客服回复时收到推送通知。不要把通知逻辑埋在 UI 代码中。把它放到“New message”流程中：当回复保存后，触发通知模块。再生成会产出更新的原生应用，而不会把变更变成手工补丁工程。

常见错误会破坏再生优先工作流

再生优先开发只有在你的应用保持可再生的情况下才有效。团队通常会犯的错误是临时快速修复，今天看似无害，但会导致明天需要变通的工作量。

1) 在生成的代码上直接编辑而不是改模型

在会被覆盖的地方混合生成部分和手工编辑，是失去干净再生成的最快方式。如果你使用的平臺会生成真实源代码（像 AppMaster 为后端、Web 与移动端生成的那样），把可视化项目当作真实来源。当需求变更时，更新数据模型、业务流程或 UI 构建器。

一个简单准则：如果你不能通过从可视化项目再生成来复现改动，那就不是安全的改动。

2) 让 UI 决定规则

当界面编码业务规则（“这个按钮只对 VIP 用户显示”、“这个表单在 UI 里计算总额”）时，每个新屏幕都会变成特殊情况。你最终会得到散落且难以一致更新的隐藏逻辑。

把校验、权限和计算放在业务逻辑中（比如 Business Process），然后让 UI 展示结果。

3) 过早设计不切实际的数据模型

过度建模看起来像是在没有真实使用的前提下添加大量字段、状态和边缘表。它会让变更变得痛苦，因为每次更新都会触及过多部分。

从你知道的开始，逐步扩展：

• 只添加能用简单语言解释的字段。
• 状态值保持简短且真实（3–6 个，而不是 20 个）。
• 与其把含义塞进一个巨表，不如稍后再新增表。

4) 跳过命名约定

命名不一致会导致模型与端点混乱："Cust"、"Customer" 与 "Client" 混在一个应用里。再生成仍能工作，但人在变更时会出错。

及早选定简单规范（单数表名、动词动作一致）并遵守它。

5) 把逻辑做成一个巨大的工作流

一个巨大的工作流起初看起来整齐，但随后就难以安全变更。把逻辑拆成小流程并保持输入输出清晰。在支持门户中，把“Create ticket”、“Assign agent”与“Send notification”分开，这样你改一个步骤不会危及其他。

在再生成与发布前的快速检查

再生优先开发只有在你有一套能抓住常见“静默断裂”问题的例行流程时才安全。再生成前做一个简短检查，按照应用的结构检查：数据、逻辑、UI 与 API。

一个快速清单：

• 数据：实体与字段符合当前需求，命名一致，且没有两个含义相同的字段。
• 逻辑：每个流程有明确输入、明确输出与可预测的错误路径。
• UI：屏幕复用共享组件，不把规则写死在界面里。
• API：端点与流程映射一致。你能回答“哪个流程驱动这个端点？”而不需要挖掘太多。
• 发布：你有简短可重复的测试脚本，而不是“随便点到看起来没问题”。

保持规则的单一真实来源。如果工单优先级依赖客户等级，就在一个流程中定义它，并让 API 与 UI 都反映这一点。

一个 10 分钟的测试脚本通常足够：

• 用仅需字段创建一条新记录。
• 触发主要流程并确认预期的状态变化。
• 尝试一个已知的错误情况（权限不足或缺少必填数据）。
• 在 Web 与移动端打开关键屏幕，确认相同的规则以相同方式展示。
• 调用一两个核心端点，确认响应与 UI 显示一致。

如果有任何失败，先修复结构（数据、流程、共享 UI），再生成一次。

下一步：在你的下一次变更中应用这个方法

先挑一个要改进的小区域，范围要小。如果最近的改动让你痛苦，从最费工的部分开始：数据模型、一段纠结的逻辑或一个不断被“稍微再改一下”的屏幕。

把下一次变更当作一次演练：调整、再生成、验证、发布。目标是让更新变得例行而非冒险。

一个简单可重复的循环：

• 做一项小改动（一个字段、一条规则或一个屏幕行为）。
• 再生成以保持代码一致。
• 运行快速冒烟测试（主路径加一个边缘例子）。
• 先部署到安全环境（staging 或测试工作区）。
• 发布并记录学到的东西。

保持一份简短的变更日志，解释决策而不仅仅记录编辑。例如："我们把工单优先级存为枚举而不是自由文本，这样当标签改变时报告不会破裂。" 两行说明能省下将来的数小时。

如果你想在不手工编辑生成产出的前提下练习这套流程，可以在 AppMaster 中构建一个小的独立模块（例如工单表单、管理列表或简单审批步骤），每次改动后再生成，注意当模型作为真实来源时应用进化会轻松多少。如果你在评估工具，appmaster.io 是一个直接的起点来试验这种工作流。

你的下一次变更就是开始的好时机。选定应用的一角，从今天起让它更易变更。