rob-pike

Rob Pike 的 5 条编程规则

规则

1. 你无法判断程序会把时间花在哪里。 瓶颈往往出现在出人意料的地方。不要猜测——要用数据证明。
2. 测量。 没有测量之前，不要针对速度进行调优。即使测量之后，除非代码中的某个部分耗时远超其他部分，否则也不要调优。
3. n 较小时，复杂算法会很慢，而 n 通常都很小。 当常数项占主导时，大 O 复杂度并不重要。先遵循规则 2。
4. 复杂算法比简单算法更容易出错。 使用简单算法和简单的数据结构。
5. 数据占主导地位。 选择合适的数据结构，算法就会显而易见。“写简单的代码，使用聪明的对象。”

如何应用

进行任何优化之前

步骤 0：检查是否已有检测机制

在问“你测量过吗？”之前，先确定目前是否能够进行测量。

扫描代码库，查找已有检测机制的迹象：

• 日志记录：查找日志记录器导入、日志调用、结构化日志库
• 性能分析：查找性能分析器导入、基准测试文件、跟踪设置
• 计时：查找耗时测量、秒表模式、计时装饰器
• APM/可观测性：查找指标导出、跨度、跟踪上下文

然后询问用户：

1. 如果已有检测机制：“我在 [locations] 中发现了日志记录/性能分析。你怀疑哪些特定区域较慢，还是我们先看看现有测量结果说明了什么？”
2. 如果检测机制缺失或稀少：“目前没有测量机制来证明时间花在了哪里。在优化任何内容之前——你怀疑瓶颈在哪里？我们先在那里添加测量，再让数据来决定。”

目标不是指定某种工具——Claude 已经了解适合该语言的性能分析方法。目标是确保在继续任何优化讨论之前，已有测量机制。 如果没有可用于测量的手段，第一步应该是添加检测机制，而不是更改代码。

步骤 1：提出测量问题

停下来，按顺序提出以下问题：

1. “我测量过吗？”——如果没有，先测量。任何没有测量数据支持的优化都是过早的。使用适合项目语言和生态系统的性能分析工具。
2. “某个部分是否耗时远超其他部分？”——如果没有任何单一区域占主导，就没有值得优化的内容。在许多区域分别进行的小幅改进通常无关紧要。
3. “n 是多少？”——如果 n 很小（而通常确实如此），简单的 O(n²) 方法很可能因常数项、缓存行为和实现复杂度而胜过巧妙的 O(n log n) 方法。
4. “这是数据结构问题吗？”——在更改算法之前，考虑换一种数据结构是否能让问题变得轻而易举。合适的数据结构往往能彻底免去使用复杂算法的必要。
5. “增加的复杂度值得吗？”——慢 10% 的简单代码几乎总是比脆弱且难以维护的复杂代码更可取。

应避免的反模式

发现自己或用户出现以下任何做法时，立即停下并引导其回到正轨：

想法	违反的规则	回应
“这个循环看起来很慢，我来优化一下”	规则 1	你做过性能分析吗？瓶颈可能完全在别处。
“我来在这里加个缓存”	规则 2	先测量。这条路径实际是否占用了大部分运行时间？
“我来用 B 树 / trie / 跳表”	规则 3	n 是多少？如果 n 很小，排序切片 + 二分查找会更快。
“我来实现一个自定义分配器”	规则 4	从简单做法开始。先测量。只有数据表明确有必要时，才采用复杂做法。
“这个算法是 O(n²)，需要修复”	规则 3	n 是多少？n=100 时，O(n²) 只需 10μs。先测量。
“我来并行化这段代码”	规则 2	这真的受 CPU 限制吗？先测量。问题往往出在 I/O。

只有在确有必要时才进行优化

仅当以下条件全部满足时，才进行优化：

• 有测量数据表明存在明确的瓶颈
• 该瓶颈占据整体运行时间的主要部分（而不只是 5-10%）
• 提出的修复方案是解决已测出问题的最简单改动
• 改动后会重新测量，以确认效果有所改善