软件工程55条黄金定律(3)有趣又有用的智慧

四、认知偏差与决策

34. Goodhart’s Law（古德哈特定律）

英文原文： When a measure becomes a target, it ceases to be a good measure. 中文翻译： 当一个衡量标准成为目标时，它就不再是一个好的衡量标准。 详细解释： 人们会优化被测量的指标，而不是真正重要的东西。例如，如果代码行数成为衡量生产力的指标，开发者会写更多的代码，而不是更好的代码。 实践建议： 谨慎选择要测量的指标。组合多个指标，并定期审查它们是否仍然衡量正确的东西。

35. Gilb’s Law（吉尔布定律）

英文原文： Anything you need to quantify can be measured in some way better than not measuring it. 中文翻译： 任何你需要量化的东西，以某种方式测量总比不测量好。 详细解释： 如果你关心某个指标，就去测量它。即使是不完美的测量也比没有测量好，因为它提供了改进的基线。 实践建议： 开始简单。即使手动跟踪也比不跟踪好。随着对测量的理解加深，再改进测量方法。

36. Dunning-Kruger Effect（邓宁-克鲁格效应）

英文原文： The less you know about something, the more confident you tend to be. 中文翻译： 你对某事了解越少，你往往越自信。 详细解释： 新手常常高估自己的能力，而专家则可能低估自己的专业知识。这创造了一个危险的”愚昧之巅”，在那里人们最自信却最无能。 实践建议： 保持谦逊。在评估自己的技能时要现实。寻求反馈，特别是来自更有经验的人的反馈。

37. Hanlon’s Razor（汉隆剃刀）

英文原文： Never attribute to malice that which is adequately explained by stupidity or carelessness. 中文翻译： 永远不要将可以用愚蠢或粗心充分解释的事情归因于恶意。 详细解释： 大多数时候，问题是由无心之失而非恶意造成的。假设恶意会导致不必要的冲突和信任破裂。 实践建议： 当事情出错时，先假设是无心之失。以教育和改进为目标，而不是指责。

38. Occam’s Razor（奥卡姆剃刀）

英文原文： The simplest explanation is often the most accurate one. 中文翻译： 最简单的解释往往是最准确的。 详细解释： 在没有证据的情况下，不要引入不必要的复杂性。如果有多个解释都符合数据，选择最简单的那个。 实践建议： 在调试时，先检查最简单的解释。不要假设复杂的阴谋论，当简单的错误就能解释问题时。

39. Sunk Cost Fallacy（沉没成本谬误）

英文原文： Sticking with a choice because you’ve invested time or energy in it, even when walking away helps you. 中文翻译： 因为你投入了时间或精力而坚持一个选择，即使放弃对你更有帮助。 详细解释： 不要因为已经投入的资源而继续错误的方向。过去的投入是不可回收的，决策应该基于未来的收益。 实践建议： 定期评估项目是否仍然值得继续。如果更好的选择出现，不要因为”我们已经投入了这么多”而拒绝改变。

40. The Map Is Not the Territory（地图不是领土）

英文原文： Our representations of reality are not the same as reality itself. 中文翻译： 我们对现实的表征与现实本身不同。 详细解释： 模型、文档和图表只是近似，不要将它们与现实混淆。任何模型都是简化，都有其局限性。 实践建议： 使用模型作为指导，但要始终验证它们是否仍然准确反映现实。当现实与模型矛盾时，相信现实。

41. Confirmation Bias（确认偏误）

英文原文： A tendency to favor information that supports our existing beliefs or ideas. 中文翻译： 倾向于支持我们现有信念或想法的信息。 详细解释： 我们倾向于寻找和记住那些证实我们观点的证据，而忽视矛盾的证据。这会导致我们坚持错误的假设。 实践建议： 积极寻找反面证据。问自己”如果我错了，我会看到什么？”鼓励团队中有人扮演”魔鬼代言人”。

42. First Principles Thinking（第一性原理思维）

英文原文： Breaking a complex problem into its most basic blocks and then building up from there. 中文翻译： 将复杂问题分解成最基本的模块，然后从那里开始构建。 详细解释： 不要接受”事情就是这样”，而是追问为什么。从最基本的事实出发，重新构建理解。 实践建议： 当面对复杂问题时，问自己：”什么是我们绝对知道的真实？”然后从这些基本事实出发构建解决方案。

43. Inversion（逆向思维）

英文原文： Solving a problem by considering the opposite outcome and working backward from it. 中文翻译： 通过考虑相反的结果并从那里倒推来解决问题。 详细解释： 思考”什么会导致失败”，然后避免这些因素。有时候，知道不做什么比知道做什么更容易。 实践建议： 在项目开始时，列出所有可能导致失败的因素，然后制定计划来避免它们。

44. Pareto Principle（帕累托原则/80-20法则）

英文原文： 80% of the problems result from 20% of the causes. 中文翻译： 80%的问题来自20%的原因。 详细解释： 专注于解决那20%的关键问题，可以带来80%的改进。这在 bug 修复、功能开发和性能优化中都适用。 实践建议： 识别那20%的高价值工作，优先处理它们。不要试图完美解决所有问题。

五、技术趋势与网络效应

45. Zawinski’s Law（扎温斯基定律）

英文原文： Every program attempts to expand until it can read mail. 中文翻译： 每个程序都试图扩展，直到它能读取邮件。 详细解释： 软件倾向于不断膨胀，添加越来越多的功能。那些原本只做一件事的程序，会逐渐增加聊天、协作、项目管理等功能。 实践建议： 保持专注。如果你的产品目标是解决一个特定问题，抵制添加”只是一个小功能”的诱惑。功能膨胀会增加复杂性和维护成本。

46. Sturgeon’s Law（斯特金定律）

英文原文： 90% of everything is crap. 中文翻译： 90%的一切都是垃圾。 详细解释： 这提醒我们，大多数尝试都会失败，只有最好的才会留下来。在软件领域，这意味着大多数项目、库和框架最终会被遗弃。 实践建议： 不要因失败而气馁。专注于持续改进。如果你创造的东西属于那10%，你就成功了。

47. Amdahl’s Law（阿姆达尔定律）

英文原文： The speedup from parallelization is limited by the fraction of work that cannot be parallelized. 中文翻译： 并行化带来的加速受限于不能并行化的工作比例。 详细解释： 即使你有无限的处理器，串行部分也会成为瓶颈。如果你的代码有10%是串行的，最大加速比就是10倍。 实践建议： 在优化并行性能之前，先减少串行部分。识别和消除瓶颈比添加更多处理器更重要。

48. Gustafson’s Law（古斯塔夫森定律）

英文原文： It is possible to achieve significant speedup in parallel processing by increasing the problem size. 中文翻译： 通过增加问题规模，可以在并行处理中实现显著的加速。 详细解释： 与阿姆达尔定律不同，如果你扩大问题规模，并行化可以更有效地扩展。当你增加工作量时，并行部分的比例可能会增加。 实践建议： 如果你可以扩大问题规模， Gustafson 定律给你更多乐观的理由。但在固定工作量的情况下，阿姆达尔定律仍然适用。

49. Metcalfe’s Law（梅特卡夫定律）

英文原文： The value of a network is proportional to the square of the number of users. 中文翻译： 网络的价值与用户数量的平方成正比。 详细解释： 每增加一个用户，网络价值都会显著增长。这就是为什么平台公司（如Facebook、微信）一旦达到临界规模，就会变得极其有价值。 实践建议： 如果你正在构建一个网络效应驱动的产品，优先达到临界规模。早期用户获取比短期收入更重要。

50. The Hype Cycle & Amara’s Law（炒作周期与阿玛拉定律）

英文原文： We tend to overestimate the effect of a technology in the short run and underestimate the impact in the long run. 中文翻译： 我们倾向于高估技术的短期影响，低估长期影响。 详细解释： 新技术刚出现时往往被过度炒作（峰值 inflated expectations），然后经历幻灭低谷（trough of disillusionment），最终达到稳定生产期（plateau of productivity）。 实践建议： 对新技术保持健康的怀疑。不要因为炒作而盲目采用，也不要因为早期失望而完全放弃。

51. The Lindy Effect（林迪效应）

英文原文： The longer something has been in use, the more likely it is to continue being used. 中文翻译： 某物使用的时间越长，它继续被使用的可能性就越大。 详细解释： 已经存在很久的技术（如C语言、SQL、TCP/IP）可能会继续存在更久。这是因为它们已经证明了自己的价值，并且有大量的生态系统和知识积累。 实践建议： 在选择技术栈时，考虑成熟技术的稳定性和社区支持。新技术可能很酷，但成熟技术可能更可靠。

六、其他重要定律

52. Law of Unintended Consequences（意外后果定律）

英文原文： Whenever you change a complex system, expect surprise. 中文翻译： 每当你改变一个复杂系统时，要预料到意外。 详细解释： 副作用是不可避免的。即使是最精心计划的变更也可能产生意想不到的后果。复杂系统中的因果关系很难完全预测。 实践建议： 进行渐进式变更，而不是大爆炸式变更。实施变更后密切监控系统，准备快速回滚。

53. Murphy’s Law（墨菲定律）

英文原文： Anything that can go wrong will go wrong. 中文翻译： 任何可能出错的事情都会出错。 详细解释： 为失败做计划，因为失败会发生。系统会宕机，网络会中断，磁盘会损坏，人会犯错。 实践建议： 构建容错系统。假设任何组件都可能失败，并设计你的系统来处理这些故障。自动化测试和监控是必需的。

54. Tesler’s Law（特斯勒定律/复杂性守恒）

英文原文： Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated. 中文翻译： 每个应用程序都有一定量的不可简化复杂性，只能转移，不能消除。 详细解释： 你可以把复杂性从用户转移到开发者，或者反之，但不能消除它。苹果的产品之所以简单易用，是因为复杂性被转移到了设计和开发团队。 实践建议： 明智地选择在哪里放置复杂性。对于消费者产品，将复杂性隐藏在产品背后。对于开发者工具，将复杂性暴露给需要它的用户。

55. Cunningham’s Law（坎宁安定律）

英文原文： The best way to get the correct answer on the Internet is not to ask a question, it’s to post the wrong answer. 中文翻译： 在互联网上获得正确答案的最好方法不是提问，而是发布错误答案。 详细解释： 人们更愿意纠正错误而不是回答问题。如果你在论坛或Stack Overflow上发布一个错误答案，很可能会有人快速纠正你。 实践建议： 当你遇到困难时，尝试提出一个解决方案，即使你可能错了。这不仅会更快地得到正确答案，还会促进更有价值的讨论。

结语

这些定律不是束缚，而是前人经验的结晶。理解并内化这些原则，能够帮助我们在软件开发的复杂世界中做出更明智的决策。

记住：

• • 没有银弹（No Silver Bullet）
• • 每个定律都有其适用场景
• • 工程是权衡的艺术