跳到正文
MyDSH我的 DSH 实战笔记
English
独立维护,非DeepSeek官方;与mydsh.dev等其他MyDSH站点无关联。

全部分类/编程与排障

写代码与测试 · 难度 进阶 · 编码 性能 优化

性能优化:先测再改

有人说这段代码慢,要优化,但没人量过。

提示词

你写代码有三个默认动作:先定输入输出的契约,再写错误分支,最后写主流程。没有错误处理的实现,你不会认为它写完了。

任务:有人说这段代码慢,要优化,但没人量过。

【动手前先做三件事】
1. 用一句话复述这件事的目标:成果最终给谁看、用来做什么决定。
2. 下面这些信息如果我没交代,直接问我,不要自己假设:
   - 当前耗时与目标
   - 调用频率
   - 瓶颈的猜测
3. 先说清你打算怎么做(不超过 5 步),等我确认再往下做。

【必须逐项过一遍】
- 先给出测量方法:基准测试或线上打点
- 区分冷启动与稳态、单次与批量
- 按「收益 = 省下的时间 × 调用次数」排序优化项
- 说明哪些优化不值得做

【工序】
1. 先写清函数或接口的契约:输入、输出、错误、副作用
2. 列出所有错误分支与边界值,先处理它们
3. 再写主流程,保持每个函数单一职责
4. 给关键路径写测试,至少覆盖一个正常、两个异常
5. 说明这段代码在什么情况下会失效

【输出】
契约 → 错误分支 → 主流程 → 测试 → 失效条件。

【不要】
- 不要忽略错误返回值
- 不要吞异常
- 不要用魔法数,写成常量并命名
- 不要在业务逻辑里直接打日志代替返回错误

开工前要交代清楚的信息

这几项没交代,模型就会自己假设一个填进去——大多数「答得不对」都是从这里开始的。

  • 当前耗时与目标
  • 调用频率
  • 瓶颈的猜测

必须逐项过一遍

这一行活最容易漏的地方。已经写进提示词了,不用你再记。

  • 先给出测量方法:基准测试或线上打点
  • 区分冷启动与稳态、单次与批量
  • 按「收益 = 省下的时间 × 调用次数」排序优化项
  • 说明哪些优化不值得做