reflect

反思

初次实现只是一个草稿。现在代码已经写好，请重新审视并思考是否有更好的实现方式。对代码和上下文提出疑问。对于不依赖产品决策的改进，直接落实。其余问题留待反馈。

目标：在用户仔细查看之前，先交付质量更高的初稿。这不是代码审查，正式审查稍后进行。

“最好”意味着：

• 用最简单的方案解决问题
• 清晰表达领域模型
• 与现有代码库协调一致
• 适时复用现有对象、辅助函数和惯例
• 不为了适配那些未针对新需求构建的现有代码而扭曲实现
• 注释解释代码的意图和依据
• 提升代码库的整体质量，为他人树立可借鉴的示例
• 采用正确的长期架构，而非只做最小改动

何时使用

• 用户说“反思”“再看看”“再过一遍”或“调整一下”
• 隐含地，在完成初次实现后使用，包括对进行中的工作进行增量修改后
• 不要在规划期间、等待设计问题答复时，或将其用作正式审查的替代

工作流程

1. 查看代码

重新阅读改动，就像第一次看到它们一样。阅读新增或修改的文件，以及它们所接入的周边模块。目标是形成高质量的最终方案，而不是最小化差异。

2. 排查并落实

逐一考虑下方的问题。对于每个不依赖产品决策的改进，直接落实。不要请求许可来改进刚写好的代码。

以下情况留待报告：

• 需要放宽、修改或移除某项需求
• 存在两种符合产品需求的路径，且无法明确判断哪种更好
• 实现过程中悄然作出了产品决策
• 需要对现有代码进行重大重构

3. 重复

每次迭代都会出现新的问题和改进机会。 重复反思和改进流程，直到问题稳定下来，或只剩下需要用户输入的产品或设计决策。

4. 报告

简要说明改了什么，然后按编号列出剩余的观察事项和决策。

等待用户回复。

问题

主要依靠自己的判断。

现在看到了代码：这是解决需求最简单、最好的方式吗？能否更简单、更直观？

针对刚写的代码，思考以下问题：

• 哪些需求导致了复杂性？是否对某些需求作了过于严格的解释？哪些需求是隐含的？对这些需求向用户提出质疑。
• 现在看到了代码，能否重新组织，让它更连贯？
• 出现了哪些简化或改进的机会？
• 核心概念是否只表达了一次，并且能够复用？
• 有没有笨拙或令人意外之处？原因是什么？
• 新代码是否在绕过代码库的缺陷？是否有直接的修复方式？
• 出现了哪些耦合？是否合理？
• 这部分内容应该放在这里，还是应该经过此处，放到更接近使用位置的地方？
• 我是否在回退或内省原本应该构建并传入的内容？
• 类似的路径或结构是否适合统一？
• 是否有两种不同方式在做同一件事？直接选一种。
• 每段代码都放在了正确的位置吗？
• 这部分内容有必要吗？它有实际作用吗？
• 可选项真的可选吗？
• 存在哪些代码异味？
• 名称是否仍然恰当，能否准确描述当前概念？
• 对整个问题而言，正确的架构是什么？
• 如果从头开始，我会采用这种方式来构建吗？
• 这是不是一种权宜之计？

未明确确认的产品决策

即使代码本身没有问题，也要报告这些决策。用户尚未确认。

• 在两种面向用户的行为中选择了一种
• 编码了某项应用规则
• 自行设定了门槛、上限、空状态或文案路径
• 选择了用户可能希望调整的默认值

不要

• 悄悄删除或放宽要求
• 臆造基类或潜在的第二个调用方
• 重命名已落地的 API 字段
• 保留变通方案
• 将其视为评审差异或提交门槛