Reference

Feature Development Lanes

这页定义团队共识:产品和后台不是只能提需求或看代码,他们可以在明确车道内开发 HappyMahjong Unity 功能。

三条开发车道

Green lane:产品可独立开发

  • 同模块 1–4 个 C# 文件
  • 文案、提示、校验、状态保护
  • 复用现有 UI / Toast / PopUp
  • 不改 Prefab / Scene / Packages

Yellow lane:后台/全栈可独立开发

  • 新增模块但使用项目模板
  • 新增 Command / Context binding
  • 新增 Inspector 字段
  • 小范围 UI 层级或 Prefab 配置
  • 新接口接入但沿用项目网络层
  • 必须提交链路证据、风险说明和验证结果

Red lane:客户端 owner 做

  • 启动 / 热更 / LoadDll
  • StrangeIoC 框架源码
  • 大规模 Scene / Prefab 重构
  • Packages / ProjectSettings / 构建
  • 不使用模板从零手写模块骨架
  • 未经审核的跨模块直接引用

产品作为实现者

产品不是只写需求。产品可以在 Green lane 内直接开发偏体验和规则的小功能。

产品可做例子必须满足
文案和提示逻辑某个操作未满足条件时显示现有提示。复用现有提示系统,不新增 UI 资源。
体验规则按钮防重复点击、失败后恢复按钮。验收覆盖连点、失败、关闭页面。
空状态 / 异常状态列表为空显示已有空状态。不改 Prefab 布局;先找现有空状态实现。
配置和开关使用某活动入口是否展示。沿用现有配置读取,不新增配置系统。

后台 / 全栈作为实现者

后台和全栈同学的目标不是只做 Green lane;他们应能独立完成 Yellow lane 中的数据、接口、DTO、状态流转、容错和验证,但必须给出链路证据、边界、风险和验证结果。

后台 / 全栈可做例子必须满足
接口接入接一个已有通道的新回包字段。沿用 TSDK / Util / Service,不写新 HttpClient。
DTO → Model 容错空数组、未知枚举、缺字段处理。不破坏旧客户端兼容。
Command / Service 流程请求中禁用按钮,回包后恢复。覆盖成功、失败、超时、取消。
日志和验证清单关键失败路径打已有风格日志。不泄露 token、openid、手机号等敏感信息。

从需求到 PR 的统一流程

1. 分级Green / Yellow / Red
2. 验收产品写场景
3. 分析agent 输出路径
4. 边界Yellow 证据更全
5. 实现限定文件
6. Diff红旗停止
7. PR验证 + 风险

模块边界规则

Definition of Ready

PR 必须包含

团队目标: 非客户端成员不是绕过客户端工程,而是在清晰车道内扩大 Unity 工程吞吐。产品 Green lane 自助,后台/全栈 Yellow lane 自助,Red lane 交给 owner;Yellow 的差别是证据和 review 要更完整。