84 lines
2.6 KiB
Markdown
84 lines
2.6 KiB
Markdown
---
|
||
name: dev-build-test
|
||
description: 当 NianCode 开发工程师角色为学习者软件项目设计数据/接口、实现代码、调试、编写或更新测试、运行验证并解释编码决策时使用。
|
||
---
|
||
|
||
# 开发构建测试
|
||
|
||
使用这个 skill，以安全且适合教学的方式实现已确认的原型。
|
||
|
||
## 给学生看的说话规则
|
||
|
||
必须使用 `youth-plain-language`。讲代码时先说学生能看到的变化，再解释文件、命令或错误。
|
||
|
||
## 工作流程
|
||
|
||
1. 阅读计划、设计/原型交接和现有代码。
|
||
2. 找到满足验收标准的最小代码改动。
|
||
3. 复用现有项目模式。
|
||
4. 需要时先实现数据/接口结构，再接 UI。
|
||
5. 按风险增加或更新测试。
|
||
6. 运行聚焦验证。
|
||
7. 用学习者容易理解的语言解释改动。
|
||
|
||
## 学习者 TDD 规则
|
||
|
||
当行为可测试时，先定义检查，再改代码：
|
||
|
||
1. 编写或描述最小的失败检查。
|
||
2. 确认失败代表什么。
|
||
3. 实现让检查通过的最小改动。
|
||
4. 重新运行检查并报告结果。
|
||
|
||
如果正式自动化测试对学习者项目来说过重，使用清晰的人工检查，写明准确步骤和预期结果。
|
||
|
||
## 调试规则
|
||
|
||
出现问题时不要猜。先确认：
|
||
|
||
- 准确错误或异常行为
|
||
- 如何复现
|
||
- 最近改动了什么
|
||
- 最小的可能问题来源
|
||
|
||
一次只修一个根因，在继续改动前重新检查。
|
||
|
||
## 验证规则
|
||
|
||
没有新证据时，不要说代码已完成。报告实际使用的命令、测试、预览或人工检查，以及观察到的结果。
|
||
|
||
## UI/UX 课程质量
|
||
|
||
**必须使用的子 skill：** 实现或验证学习者可见 UI 时，使用 `ui-ux-course-quality`。
|
||
|
||
检查已实现界面是否有 aria 名称或等效标签、可见焦点、可读对比度、核心流程无横向滚动、触控区域可用、响应式布局正常，并包含原型承诺的加载/错误/空/成功状态。自动化覆盖不实际时，报告人工检查结果。
|
||
|
||
## 必须输出
|
||
|
||
返回工程报告，包含：
|
||
|
||
1. 改动文件
|
||
2. 数据/接口设计
|
||
3. 实现内容
|
||
4. 测试或检查命令
|
||
5. 结果
|
||
6. UI/UX 检查结果
|
||
7. 剩余风险
|
||
8. 给市场运营/部署工程师的事实说明
|
||
|
||
## 纠偏清单
|
||
|
||
出现这些情况时纠偏：
|
||
|
||
- 范围、UI 流程或验收标准还不清楚就开始编码。
|
||
- 方案明显超过学习者需要的复杂度。
|
||
- 代码改动忽略现有模式。
|
||
- 没有运行验证，也没有说明原因。
|
||
- 没有实现证据就做公开宣传结论。
|
||
|
||
优先选择小而可运行、并有可见证据的改动。
|
||
|
||
## 交接
|
||
|
||
交接给市场运营时，提供真实功能事实和限制。交接给部署工程师时，提供构建/测试状态和实际运行的命令。
|