黑客启发式：在没有‘Correct’答案的世界中生存的思维捷径

I’m happy to translate the article for you, but I don’t see the article text in your message—only the source link. Could you please paste the content you’d like translated (or let me know if you’d like me to retrieve it from the link)? Once I have the text, I’ll provide a full Simplified Chinese translation while preserving the original formatting.

介绍

现在是2026年。我们处理的系统已经超出了任何单个人类能够完全理解的极限。这正是heuristics成为工程师最强大武器的地方：务实的“足够好”答案源自经验，使我们能够瞬间得到解决方案。我对这些heuristics产生了兴趣，并在下方汇编了它们。

黑客启发式

评估函数

当计算复杂度爆炸时，使用一种称为评估函数的快捷方式。与其检查迷宫中的每条路径，不如优先考虑看起来更接近目标的路径。

贪婪扩容

放弃“预测整个未来”，而是一次又一次地选择“此时此刻的最佳选项”。
应用场景： 云资源扩容。Kubernetes HPA（水平 Pod 自动伸缩器）本质上就是基于这种贪婪方法。规则“最近负载上升，所以现在添加一个 Pod”在运维中比尝试基于未来预测进行严格成本计算要稳健得多。

CAP 权衡直觉

网络分区是不可避免的。现在就决定是牺牲一致性还是可用性。在分布式系统中，满足 CAP 定理的全部三项在数学上是不可能的。这种“妥协”启发式可以大幅缩短设计时间。

康威定律在微服务中的体现

任何设计系统的组织，必然会产生结构上镜像组织沟通结构的设计。
实践： 在划分微服务边界时，先观察团队之间的对话在哪里停止，再去追求技术上的最优。让组织结构图与服务边界保持一致，能够得到摩擦最小的设计。

缓存密集的读工作负载

如果数据读取的频率远远超过写入，毫不犹豫地进行缓存。大多数情况下，添加一层 Redis 比花时间优化复杂查询更快地达到“足够好”的解决方案。

从简到繁演进

一个可用的复杂系统必然是从一个可用的简易系统演进而来。
实践： 不要一开始就构建庞大的微服务。先构建一个作为“最小可正确运行单元”的单体应用，然后再逐步演进。

保留防御性栅栏

在弄清楚设置栅栏的原因之前，不要将其移除。
实践： 当遇到看不懂的校验逻辑时，先不要删除，等弄明白原始工程师为何加入这段防御代码再决定。

延迟抽象

在同一段代码写了三遍之前，不要急于抽象（公共化）。过早抽象会让后续修改变得困难。容忍复制粘贴到第三次出现，然后在共享结构确定后再抽象。
Go 谚语： “少一点复制胜过少一点依赖。”

保持实体最小化

实体不应被不必要地增多。最简单的解释往往是正确的。面对神秘的故障时，先怀疑最近的配置更改或一个简单的拼写错误，而不是立即归咎于内核 bug 或零日漏洞。

帕累托性能

80 % 的性能问题来源于 20 % 的代码。对每个函数都进行优化是浪费。使用分析工具（例如 pprof）找出热点，集中精力在这些关键点上。

Nielsen 的 UI 原则（在 2026 年仍然适用）

• 反馈： 系统应始终通过适当的反馈在合理的时间内让用户了解正在发生的事情。
  实践： 当运行耗时的异步处理时，显示进度条或骨架屏，而不是静态的“Processing…”提示。

• 使用用户语言： 使用用户熟悉的词汇、短语和概念，而不是系统导向的术语。
  实践： 将 “Error 500: Internal Server Error” 替换为更友好的信息，例如 “我们目前连接出现问题，请稍后几分钟再试”。

错误预防

“比起好的错误信息，更好的做法是精心设计，使问题在一开始就被防止发生。”

• 防止无效输入： 与其在用户选择过去的日期时显示错误，不如在日历上将过去的日期设为不可选（灰显）。从一开始就构建防止错误操作的机制。

• 关注核心问题： 人们会对琐碎的事物（例如自行车棚的颜色）激烈争论，却对复杂的事物（例如核电站的设计）保持沉默。
  实践： 停止花一个小时审查代码中的空格数量。把讨论引导到大家因为困难而回避的核心架构上。

• 避免不匹配的优化： 在项目能够进入下一步之前，需要完成一系列小任务。如果你为了“开发新功能”而开始“优化容器镜像大小”，请问自己：“我现在是否在朝原始目标前进？”

结束语

启发式并不是对质量的妥协；它们是一种生存策略，用于将有限的资源聚焦在真正重要的问题上。在信息噪声持续增加的时代，工程师并不需要了解所有事物。相反，他们依赖于一个 直觉目录，它告诉：“在这种情况下，这条原则应该有效”，从而让他们能够自信地选择捷径。

如果你还有其他有趣或喜欢的启发式，请在评论中分享。