精简代码路径
从一个真实操作开始。调用方显示或作用于什么？沿着该需求追踪API、服务、中间件、ORM以及执行的SQL。在受影响路径上尽可能早地消除不必要的工作。在常规开发中使用简单、低成本的代码。在引入更复杂的优化之前先定位瓶颈。
实现规则
- 重用请求中已有的数据。只要操作支持，就批量处理查询、写入和远程调用。在遇到实际限制时拆分批量。检查批量API内部是如何实现的。并行处理每个项仍然会导致每个项一次往返。
- 根据访问模式选择数据结构。在现有集合中扫描以进行单次查找。对于重复匹配，一次性构建键控映射。将不变的解析和计算移出循环。在热路径上，消除重复排序、大型复制以及未使用的中间集合。在进程内传递现有值，而不是通过JSON往返来转换相同形状的数据。
- 在外部输入进入的地方进行解析和验证。内部函数可以直接使用入口点已检查过存在性、类型或范围的值。在添加防御性分支之前，先识别可到达的输入以及该分支要防止的故障。在代码可以恢复、添加有用上下文或将其转换为不同错误契约的地方捕获错误。
- 在读写谓词中尽可能包含所有权。通过受信任的模块、调度器和执行器传递已验证的任务标识、所有权和参数。同一任务内的握手、回调或委托本身不需要另一次检查或查找。当涉及新的输入或独立的信任边界时，验证接收方无法继承的保证。对于可变条件（如余额、先前的状态和幂等性），在依赖于它们的写入上以原子方式强制执行。
- 使用合适的框架默认值，或在适当的地方定义一次固定规则。仅为实际的部署差异、独立的调优需求或明确的用户请求添加配置设置。优先使用现有的配置或密钥存储。仅在现有机制无法满足需求时才创建文件。仅在请求时才添加功能开关。
- 优先使用唯一约束、条件写入、原子递增和短事务。在添加应用级锁之前，确定竞争的操作、错误的结果，以及为什么现有机制无法阻止它。锁定最小的资源，持续时间最短。在移除现有锁之前，检查每个写入者和任何延迟结果。
- 保留访问规则、排序、分页、部分成功语义、输出质量和恢复。与用户讨论对行为或成本的实质性更改。重用项目中的中间件、测试入口点和验收标准。
阅读相关参考
验证
- 在授权的测试环境中，通过实际应用入口点来执行已更改的API。检查响应、受影响的调用方以及最终的业务状态。在修剪字段时，检查实际载荷，对于基于数据库的路径，检查执行的SQL。对于批量操作，比较小批量与大批量的查询次数。当涉及副作用时，测试相关的竞争、重复请求或恢复路径。通过其正常入口点验证后台作业和本地计算，并检查其输出。遵循项目要求的检查和CI。
- 用户负责可视化和手动的Web验收。移交页面、操作和预期结果，并将该验收标记为待处理。对于前端更改，运行相应的构建、类型或交互检查。如果用户委托进行浏览器测试，则覆盖所请求的范围。
- 用相同环境下、相同数据和并发条件下的前后对比测量来支持加速声明。记录样本计数和缓存状态。选择能够暴露所调查成本的指标，例如尾延迟、吞吐量、查询计数、扫描行数、传输字节数或峰值内存。对于异步工作，区分接受、队列延迟和完成。单次运行报告为单次运行。如果没有可比较的基线，只报告测量到的内容。保持验证与变更规模成比例。