React 管理台项目复盘

学习目标

完成或核对 p2-data-workbench(React 数据管理台)之后,这一课带你做一次系统的代码审查与复盘:按数据、请求、表单、测试、性能五个维度过一遍关键决策,产出一份能说服他人的复盘文档,并演练「解释自己代码」的表达。

问题场景

项目做完的常见状态:功能都通,但被问「为什么这里用乐观更新」时答不上来;或者当初做对了,却说不出对在哪。复盘不是走过场——它是把项目经验变成可迁移判断的唯一一步,也是协作与面试里真实会被考察的能力:为自己的每个关键决策给出依据、代价与替代方案。

核心解释

**项目说明。**到 /projects 页找到「React 数据管理台(p2-data-workbench)」:它是课程数据的增删改查工作台,覆盖列表展示与筛选、表单编辑与异步校验、写操作的乐观更新、行为测试与性能优化。动手任务指向该项目的完成与核对;本课正文是复盘方法论,配套实验区提供可交互的检查卡。

审查清单:五个维度,每维度找出一处「最能代表你思考」的代码:

维度	审查问题	关联课程
数据	远程/筛选/临时状态分类存放了吗?同一数据单源吗?派生值进 state 了吗?	R41
请求	缓存键完整吗?竞态有守卫吗?失败能重试吗?写入后失效了吗?	R42/R43
表单	异步校验会过期落地吗?提交状态独立吗?字段依赖重校验了吗?	R44
测试	测的是行为还是实现?异步五状态都有覆盖吗?搜得到裸 sleep 吗?	R49/R50
性能	每处 memo 都有测量数据支撑吗?优化前后数字归档了吗?	R34/R35/R51

**结论的表达格式:四元组。**每个关键决策按「决策 → 依据 → 代价 → 替代方案」写,例如:

决策:收藏操作使用乐观更新
依据:操作高频、失败率低,即时反馈对体验影响大
代价:需要快照回滚与连点防抖,状态逻辑复杂度上升
替代:提交后整体刷新(放弃即时反馈,换实现简单)

审查标注也讲究落点:结论要能指到具体代码,而不是复述设计初衷。

// 审查标注示例:为什么持久化不放在渲染副作用里
function addTask(task) {
  const next = [...tasks, task];
  setTasks(next);
  persist(next); // 写后即存:动作发生时显式保存,写入时机与用户动作一一对应
}

**复盘会怎么开。**团队语境下建议 40 分钟结构:10 分钟核心链路现场走查、15 分钟对照上表过五个维度、10 分钟挑两处「如果重来会不同」的决策深挖、5 分钟产出行动项。「如果重来」最有价值——它逼你显式承认当初信息不足时下的注。注意区分「真失误」(信息足够却没做)与「合理代价」(当时信息下的正确选择):复盘不追求完美,追求决策过程可解释。

示例拆解

实验区是一张可交互的「复盘检查卡」:五个维度各 3 个检查项,逐项勾选并在输入框里填证据位置(如「见 useCourses L12」);右上角实时汇总完成度,勾选与笔记存进 localStorage,可以边做项目边回来更新。用它代替纸面清单完成你对 p2-data-workbench 的审查。

动手任务

正式任务在 /projects 页的「React 数据管理台(p2-data-workbench)」:

1. 完成或核对项目实现后,用实验区检查卡过一遍五个维度,每项勾选并填写证据位置。
2. 挑三个关键决策写成四元组(决策/依据/代价/替代方案),作为复盘文档的骨架。
3. 把复盘文档讲给另一个人(或对着录像讲)一次:重点练习「为什么不做 X」——否定一个方案的 reasoning 比夸自己更难表达。

常见错误

• 复盘写成功能清单:「实现了 A/B/C」是提交说明不是复盘;复盘的对象是决策与代价。
• 只报喜不报忧:没暴露失败判断的复盘没有复利;「如果重来」必须至少产出一条真实反思。
• 结论没有证据:「性能优化过了」拿不出前后数字,等于没优化;每个结论挂证据位置。
• 把审查做成自夸:用清单的原始问题逐条逼问自己,而不是复述当初为什么这么做。

检查与复盘

自查清单:

• 五个维度的检查卡全部勾完,每项有证据位置
• 复盘文档含三个四元组决策与至少一条「如果重来」
• 能在不看代码的情况下讲清两个关键决策的依据与代价

参考资料

• React 官方文档:你可能不需要 Effect —— 请求/同步类决策的官方判断标准
• React 官方文档:选择状态结构 —— 数据维度审查的依据
• React 官方文档:React DevTools —— 审查时核对真实 props/state 的工具