汇集塑造软件系统、团队和决策的 56 条原则与模式
"过早优化是万恶之源" —— 但 97% 的情况下，你并不需要它
📑 目录
- 🏗️ 架构 (Architecture)
- 👥 团队 (Teams)
- 📋 规划 (Planning)
- ✨ 质量 (Quality)
- 📈 扩展 (Scale)
- 🎨 设计 (Design)
- 🤔 决策 (Decisions)
1. 架构 (Architecture)
1.1 康威定律 (Conway's Law)
"Organizations design systems that mirror their own communication structure."
详细解释
康威定律 (Conway's Law) 指出，软件系统的结构会反映构建该系统的组织的沟通结构。Melvin Conway 于 1967 年提出这一概念，他观察到设计系统的组织受限于产生与其沟通结构相同的设计。这意味着软件的架构会反映团队的沟通方式——如果团队之间缺乏沟通，最终可能会产生集成性差的分布式微服务。相反，紧凑整合的团队会产生更具内聚性的单体系统。
要点
- 软件架构反映组织的沟通模式
- 要改变软件架构，可能需要改变团队的沟通结构
- 跨职能团队 (Cross-functional Teams) 往往产生更集成的系统
- 康威定律是双向的——组织变革可以促成新的架构模式
起源
- 由计算机科学家 Melvin Conway 于 1967 年提出
- 发表于 1968 年的论文《How Do Committees Invent?》
1.2 海勒姆定律 (Hyrum's Law)
"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended upon by somebody."
详细解释
海勒姆定律 (Hyrum's Law) 指出，无论你在合同中承诺什么，当 API 有足够多的用户时，你系统的所有可观察行为都会被某些人依赖。如果你的 API 以特定顺序返回数据、依赖时序或有副作用，用户都会构建依赖这些行为的系统。当你修复"bug"或改变行为时，你会破坏他们的系统。
要点
- 所有可观察行为都成为隐式依赖
- 即使是修复 bug 也可能破坏依赖该 bug 行为的用户
- 仅靠文档无法防止这种情况——只有隐藏行为才能防止依赖
- 用户多的 API 在其可观察行为上基本上是不可变的
- 设计 API 时假设每个细节都会被发现和依赖
起源
- 由 Google 高级工程师 Hyrum Kaplan 制定
- 也称为"隐式依赖定律 (Law of Implicit Dependencies)"
1.3 盖尔定律 (Gall's Law)
"A complex system that works has invariably evolved from a simple system that worked."
详细解释
盖尔定律 (Gall's Law) 强调，成功的复杂系统不是从零开始设计的，而是从简单的工作基础逐步演进的。试图一次性构建复杂系统会失败，因为不可能预见组件相遇时出现的所有交互和挑战。第一个系统可能很丑陋，但它教会你第二个系统需要什么。
要点
- 从简单开始并迭代——复杂性自然出现，不要强加
- 首先构建一个可工作的简单系统，然后逐步添加功能
- 预先设计复杂系统很容易失败
- 演进 (Evolution) 胜过革命 (Revolution)
起源
- 由 John Gall 在《Systemantics: How Systems Really Work and How They Fail》(1975)中制定
1.4 抽象泄漏定律 (The Law of Leaky Abstractions)
"All non-trivial abstractions, to some degree, are leaky."
详细解释
抽象泄漏定律 (The Law of Leaky Abstractions) 由 Joel Spolsky 提出，指出没有抽象是完美的——底层现实会"泄漏"出来。例如，TCP 提供了可靠网络通信的抽象，但有时底层网络的不可靠性会泄漏出来。同样，ORM 抽象了数据库细节，但偶尔你必须理解 SQL。
要点
- 抽象会泄漏——预期要理解底层机制
- 每一层抽象都增加其自身的故障模式
- 不要依赖抽象来永久隐藏所有复杂性
- 抽象层越多，泄漏的机会越多
起源
- 由 Joel Spolsky 在 2002 年的博客文章中提出
1.5 泰斯勒定律 (Tesler's Law)
"Every application has an inherent amount of complexity that cannot be reduced."
详细解释
泰斯勒定律 (Tesler's Law) 也称为复杂性守恒定律 (Law of Conservation of Complexity)，指出每个系统都有一定量的无法减少的复杂性。系统总复杂性是用户复杂性加上开发者复杂性之和。你可以在各处转移复杂性——通过在幕后增加复杂性来简化用户界面——但你无法减少总量。
要点
- 复杂性无法消除，只能在用户和系统之间转移
- 通过在幕后处理复杂性为用户构建简单性
- 接受某些问题本质上很复杂
起源
- 归因于 Larry Tesler，前苹果员工
- 在 Xerox PARC 和苹果的人机交互工作中开发
1.6 CAP 定理 (CAP Theorem)
"A distributed data store can provide only two of the three guarantees simultaneously: Consistency, Availability, and Partition tolerance."
详细解释
CAP 定理 (CAP Theorem) 也称为布鲁尔定理 (Brewer's Theorem)，指出任何分布式数据存储只能同时提供三种保证中的两种：一致性 (Consistency)、可用性 (Availability) 和分区容错 (Partition Tolerance)。由于网络分区在分布式系统中不可避免，真正的选择是在一致性和可用性之间。
要点
- 你不能同时拥有三者：一致性、可用性、分区容错
- 根据需求选择：CP（专注一致性）或 AP（专注可用性）
- 分区容错不是可选的——分区会发生
- 现代系统通常优先考虑可用性和最终一致性 (Eventual Consistency)
起源
- 由加州大学伯克利分校的 Eric Brewer 教授于 1998 年提出
- 2002 年由 Seth Gilbert 和 Nancy Lynch 数学证明
1.7 第二系统效应 (The Second-System Effect)
"Small, successful systems tend to be followed by overengineered, bloated replacements."
详细解释
第二系统效应 (The Second-System Effect) 描述了架构师和开发者在第二个系统上过度修饰的倾向。在成功完成第一个（通常是简单、保守的）系统后，开发者充满信心并积累了第一个项目中推迟的想法。第二个系统试图包含所有这些推迟的想法，往往导致功能过度复杂、臃肿的系统而失败。
要点
- 对第二个主要系统保持谨慎——抵制功能膨胀 (Feature Bloat)
- 第一个系统往往太简单；第二个系统有变得太复杂的风险
- 将合法的改进与功能蔓延分开
起源
- 由 Fred Brooks 在《The Mythical Man-Month》(1975)中识别
1.8 分布式计算的谬误 (Fallacies of Distributed Computing)
"A set of eight false assumptions that new distributed system designers often make."
详细解释
分布式计算的谬误 (Fallacies of Distributed Computing) 是分布式系统设计者做出的八个错误假设，最终导致项目失败。它们最初由 Sun Microsystems 的 L. Peter Deutsch 提出：
- 网络是可靠的
- 延迟为零
- 带宽是无限的
- 网络是安全的
- 拓扑不会改变
- 只有一个管理员
- 传输成本为零
- 网络是同质的
要点
- 网络故障不是例外——它们经常发生
- 始终为失败设计 (Design for Failure)——假设网络会有问题
- 明确处理延迟——不要假设即时通信
起源
- 最初由 Sun Microsystems 的 L. Peter Deutsch 在 1990 年代制定
1.9 意外后果定律 (The Law of Unintended Consequences)
"Whenever you change a complex system, expect surprise."
详细解释
意外后果定律 (The Law of Unintended Consequences) 指出，有意的行为总是会产生非预期的后果。在软件工程中，这表现为：修复一个 bug 会创建另一个，添加功能会破坏现有功能，重构代码会引入新的边缘情况。
要点
- 始终彻底测试——意外后果很常见
- 生产中的变化可能产生级联后果
- 部署后密切监控系统以发现意外行为
起源
- 根植于社会学和经济学（Robert K. Merton，1936）
1.10 扎温斯基定律 (Zawinski's Law)
"Every program attempts to expand until it can read mail."
详细解释
扎温斯基定律 (Zawinski's Law) 指出，软件倾向于随着时间积累功能（功能蔓延 / Feature Creep），直到它变得臃肿并试图做所有事情。即使是具有明确原始目标的应用程序也倾向于扩展以包含越来越多的功能，往往以牺牲性能、简单性和可靠性为代价。
要点
- 功能蔓延几乎不可避免——计划或积极抵制它
- 程序倾向于臃肿——用有纪律的范围控制来对抗
- 单一用途工具通常优于臃肿的替代品
起源
- 由 Netscape 工程师和 Mozilla 开发者 Jamie Zawinski 提出
2. 团队 (Teams)
2.1 布鲁克斯定律 (Brooks's Law)
"Adding manpower to a late software project makes it later."
详细解释
布鲁克斯定律 (Brooks's Law) 是软件项目管理中最著名且违反直觉的原理之一。原因是新人员需要培训（占用现有员工的时间），沟通开销增加，新团队成员没有现有代码库的上下文知识。净结果是给人手不足的项目增加人员会进一步延迟它，而不是加速它。
要点
- 更多人并不意味着复杂项目交付更快
- 新团队成员需要入职时间并增加沟通复杂性
- "人月"不是可互换的
- 最好接受延迟，而不是用更多资源来加重延迟
起源
- 由 Fred Brooks 在《The Mythical Man-Month》(1975)中提出
- 基于 Brooks 管理 IBM OS/360 项目的经验
2.2 邓巴数字 (Dunbar's Number)
"There is a cognitive limit of about 150 stable relationships one person can maintain."
详细解释
邓巴数字 (Dunbar's Number) 约150，是一个社区的规模，在这个社区中每个人都相互认识身份和角色。在软件组织中，超过这个规模的团队可能会遇到协调挑战。
要点
- 人类认知限制了我们可以有效维护的关系数量
- 大团队需要更多的结构和流程来弥补
- 考虑将大型组织分解为较小的自治团队
起源
2.3 林格曼效应 (The Ringelmann Effect)
"Individual productivity decreases as group size increases."
详细解释
林格曼效应 (The Ringelmann Effect) 指出，随着更多人一起工作，个人努力会减少。在软件团队中，随着团队规模增长，每个人的生产力经常下降。
要点
- 团队越大，个人贡献越少
- 沟通开销增加
- 责任分散导致"搭便车"
- 保持小团队以保持生产力
起源
- 以法国农业工程师 Max Ringelmann 命名
2.4 普赖斯定律 (Price's Law)
"The square root of the total number of participants does 50% of the work."
详细解释
普赖斯定律 (Price's Law) 表明，简单地雇佣更多开发人员不会必然扩展输出。超过一定程度，许多人可能贡献甚少。在任何群体中，大约只有 √N 的人做了一半的工作。
要点
- 招聘更多人不会自动提高生产力
- 识别并授权给高贡献者
- 不要假设所有团队成员贡献相等
起源
- 源自 Derek J. de Solla Price 的工作
2.5 帕特定律 (Putt's Law)
"Technology is populated by hierarchically arranged technicians, guided by the conviction that any organization that follows the traditional manager spawns avenues of limited intelligence."
详细解释
帕特定律 (Putt's Law) 解释了一个概念：最好的工程师不在管理岗位，而那些在管理岗位的不深入了解技术。虽然不是普遍的，但在科技组织中这种模式很常见。
要点
- 技术人员和管理人员通常有不同的技能和兴趣
- 技术能力不等于管理能力
- 好的技术领导需要两者的结合
起源
2.6 彼得原理 (The Peter Principle)
"In a hierarchy, every employee tends to rise to their level of incompetence."
详细解释
彼得原理 (The Peter Principle) 解释了为什么组织最终会有平庸的经理。一位优秀的工程师被提升为技术主管，但在新角色中挣扎，因为晋升是基于前一角色的能力，而不是新角色的能力。
要点
- 晋升基于当前角色表现，而非未来角色能力
- 技术优秀者不一定是好的管理者
- 考虑创建平行的技术轨道 (Technical Track)
起源
- 由 Dr. Laurence Peter 和 Raymond Hull 于 1969 年制定
2.7 公交车因子 (Bus Factor)
"The minimum number of team members whose loss would put the project in serious trouble."
详细解释
公交车因子 (Bus Factor) 为1意味着一个人持有关键知识；如果他们消失，项目基本上会停滞。更高的公交车因子意味着知识分布在更多团队成员中，降低风险。
要点
- 记录知识并进行交叉培训 (Cross-training)
- 避免单一知识点故障
- 定期进行知识分享会议
2.8 迪尔伯特原则 (The Dilbert Principle)
"Companies tend to promote incompetent employees to management to limit the damage they can do."
详细解释
迪尔伯特原则 (The Dilbert Principle) 说无能的员工经常被提升到管理层，以让他们离开。这与彼得原理相辅相成。
要点
起源
- 由 Scott Adams（Dilbert 创作者）提出
3. 规划 (Planning)
3.1 过早优化 (Premature Optimization)
"Premature optimization is the root of all evil."
详细解释
过早优化 (Premature Optimization) 指的是在有足够信息证明需要优化之前优化代码或系统设计。Donald Knuth 的名言："我们应该忘记小的效率，大约 97% 的时间：过早优化是万恶之源。"
要点
- 在优化之前进行性能分析 (Profiling)——不要猜测在哪里进行性能问题
- 首先编写清晰、正确的代码；只有在有明确需要时才优化
- 关注算法改进（Big O）而非微优化
- 97% 的时间，小优化不重要
起源
- 由 Donald Knuth 在 1974 年图灵奖演讲中推广
3.2 帕金森定律 (Parkinson's Law)
"Work expands to fill the time available for its completion."
详细解释
帕金森定律 (Parkinson's Law) 常用于警告宽松的截止日期会降低生产力，所以团队应该设置清晰、现实的时间限制。
要点
- 设置紧迫但现实的截止日期
- 避免开放式时间框
- 使用帕金森定律来对抗功能蔓延
起源
- 由 C. Northcote Parkinson 于 1955 年制定
3.3 九十九十规则 (The Ninety-Ninety Rule)
"The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%."
详细解释
九十九十规则 (The Ninety-Ninety Rule) 警告说项目的最后 10% 会花费与前 90% 同样长的时间。它强调了软件开发的固有不确定性和完成复杂项目的挑战。
要点
- 计划为最后阶段分配足够时间
- 接受估算的不确定性
- 缓冲时间用于集成和测试
起源
3.4 霍夫施塔特定律 (Hofstadter's Law)
"It always takes longer than you expect, even when you take into account Hofstadter's Law."
详细解释
霍夫施塔特定律 (Hofstadter's Law) 强调了复杂创造性工作（如软件开发）中固有的不确定性。通常有隐藏的任务、计划外的并发症和使估计困难的未知数。
要点
- 总是添加缓冲时间
- 使用历史数据进行更准确的估计
- 接受估计永远不会是完美的
起源
- 由 Douglas Hofstadter 在《哥德尔、艾舍尔、巴赫》(1979)中制定
3.5 古德哈特定律 (Goodhart's Law)
"When a measure becomes a target, it ceases to be a good measure."
详细解释
古德哈特定律 (Goodhart's Law) 来自经济学，对软件团队非常相关。例如，管理者可能设定目标"每天必须关闭 10 个 bug"，然后开发者可能会专注于简单的 bug 或创建 bug 来关闭，操纵指标而不是提高质量。
要点
- 警惕指标游戏 (Gaming the Metric)
- 使用多个指标而不是一个
- 定期审查指标的有效性
起源
3.6 吉尔布定律 (Gilb's Law)
"Anything you need to quantify can be measured in some way better than not measuring it."
详细解释
吉尔布定律 (Gilb's Law) 断言，即使是大致或间接的测量也比没有好。当某事是重要的（性能、客户满意度、代码质量），一些测量比没有测量好。
要点
起源
4. 质量 (Quality)
4.1 童子军规则 (The Boy Scout Rule)
"Always leave the code better than you found it."
详细解释
童子军规则 (The Boy Scout Rule) 源自童子军的座右铭"离开营地时比发现时更干净"，这一原则要求开发者在他们接触的任何代码上进行增量改进。
要点
- 做小的、持续的改进，而不是大规模的重构尝试
- 许多小改进的组合效果会随着时间累积
- 关注" scavenger "提交而不是专门的重构冲刺
起源
- 由 Robert C. Martin (Uncle Bob) 在软件工程环境中推广
4.2 墨菲定律 (Murphy's Law)
"Anything that can go wrong will go wrong."
详细解释
墨菲定律 (Murphy's Law) 强调防御性编程 (Defensive Programming)、错误处理和为边缘情况做准备的重要性。在软件中，这意味着假设任何可能失败的事情都会失败，并构建能够优雅处理故障的健壮系统。
要点
- 假设任何可能失败的事情都会失败
- 实施防御性编程
- 优雅地处理错误
起源
- 以 Captain Edward A. Murphy (1949) 命名
4.3 波斯特尔定律 (Postel's Law)
"Be conservative in what you do, be liberal in what you accept from others."
详细解释
波斯特尔定律 (Postel's Law) 有两条规则：
- 当你的系统发出数据或与外部世界交互时，严格遵守协议和标准
- 接收数据时，优雅地处理变化、轻微的协议偏差和意外输入
要点
起源
- 由 Jon Postel (RFC 761) 制定
4.4 破窗理论 (Broken Windows Theory)
"Don't leave broken windows (bad designs, wrong decisions, or poor code) unrepaired."
详细解释
破窗理论 (Broken Windows Theory) 由《程序员修炼之道》一书推广。在城市里，未修复的破窗表示忽视并吸引更多故意破坏。同样，在代码中，明显的问题或混乱的部分未处理可能导致更多开发者绕过流程或引入更多混乱。
要点
- 质量问题如果不解决会雪球般变大
- 快速修复小问题
- 保持高标准
起源
- 来自犯罪学（James Q. Wilson 和 George Kelling，1982）
- 在软件中，由 Andy Hunt 和 Dave Thomas 在《程序员修炼之道》(1999)中应用
4.5 技术债务 (Technical Debt)
"Technical Debt is everything that slows us down when developing software."
详细解释
技术债务 (Technical Debt) 凸显了软件工程中的一个基本张力：速度与质量。这一术语帮助向开发者和非技术利益相关者解释为什么看似"完成"的软件仍然需要持续工作。
要点
起源
- 由 Ward Cunningham（敏捷宣言的作者之一）于 1992 年在 OOPSLA 会议上创造
4.6 林纳斯定律 (Linus's Law)
"Given enough eyeballs, all bugs are shallow."
详细解释
林纳斯定律 (Linus's Law) 也称为开放源代码定律 (Open Source Law)，Linux 的开放开发模式导致快速发现 bug。当很多人使用和审查一段软件时，问题对某些人来说是显而易见的。
要点
- 透明度和协作导致更健壮、可靠的软件
- 代码审查 (Code Review) 和结对编程是有效的
起源
- 以 Linus Torvalds 命名，但实际上来自 Eric S. Raymond
4.7 凯宁汉定律 (Kernighan's Law)
"Debugging is twice as hard as writing the code in the first place."
详细解释
凯宁汉定律 (Kernighan's Law) 说调试需要理解代码实际上做什么，这可能是编写代码的两倍难。当编码时，你使用特定的模型和完整上下文进行操作。当调试时，你可能处理别人的代码或你自己的代码后上下文已经消失。
要点
- 编写"聪明"或复杂的代码本质上是为你未来的自己设置陷阱
- 可维护的版本通常优于优化的版本
起源
4.8 测试金字塔 (Testing Pyramid)
"A project should have many fast unit tests, fewer integration tests, and only a small number of UI tests."
详细解释
测试金字塔 (Testing Pyramid) 是一个视觉隐喻：最大的层级（在底部）是单元测试，它们最快且数量最多。中间层是集成测试，数量较少。顶部是 UI/端到端测试，数量最少。
要点
- 大多数 bug 在最便宜的层级被捕获
- 如果金字塔倒置（大量端到端测试，很少单元测试），测试套件往往慢且脆弱
起源
4.9 农药悖论 (Pesticide Paradox)
"Repeatedly running the same tests becomes less effective over time."
详细解释
农药悖论 (Pesticide Paradox) 指出，每次你用同样的测试测试软件，你只是验证了软件通过了那些测试，而不是新的 bug。
要点
4.10 莱曼软件演化定律 (Lehman's Laws)
"Software that reflects the real world must evolve, and that evolution has predictable limits."
详细解释
莱曼定律 (Lehman's Laws) 是关于软件系统随时间演化的预测：
- 持续变化定律：软件系统必须不断变化，否则会逐渐变得无用
- 复杂度增加定律：随着软件演化，其复杂性会增加
- 质量下降定律：系统质量会随着演化下降
要点
起源
4.11 斯特金定律 (Sturgeon's Law)
"90% of everything is crap."
详细解释
斯特金定律 (Sturgeon's Law) 指出，90% 的东西都是垃圾。在软件工程中，这意味着大多数代码、特性、项目都是平庸或更差的。
要点
起源
5. 扩展 (Scale)
5.1 阿姆达尔定律 (Amdahl's Law)
"The speedup from parallelization is limited by the fraction of work that cannot be parallelized."
详细解释
阿姆达尔定律 (Amdahl's Law) 指出，当你添加 CPU 核心时，只有你的代码的可并行化部分加速。顺序部分保持不变，最终主导总执行时间。
要点
- 并行化的收益是有限的
- 识别顺序瓶颈
- 优化顺序部分以获得最大收益
起源
5.2 古斯塔夫森定律 (Gustafson's Law)
"It is possible to achieve significant speedup in parallel processing by increasing the problem size."
详细解释
古斯塔夫森定律 (Gustafson's Law) 指出，通过增加问题规模，可以在并行处理中获得显著的加速。与阿姆达尔定律关注固定问题大小不同，这一定律表明你可以调整问题大小以从并行化中获益更多。
要点
- 不要固守固定问题大小
- 考虑增加问题规模以利用并行性
起源
5.3 梅特卡夫定律 (Metcalfe's Law)
"The value of a network is proportional to the square of the number of users."
详细解释
梅特卡夫定律 (Metcalfe's Law) 指出网络的价值与用户数量的平方成正比。在软件中，这适用于平台、API 和网络效应 (Network Effects)。
要点
起源
6. 设计 (Design)
6.1 YAGNI (你不需要它)
"Don't add functionality until it is necessary."
详细解释
YAGNI (You Aren't Gonna Need It) 是极限编程 (XP) 中的一个原则，指出程序员不应该添加实际上不需要的功能。核心思想是"以防万一"或"为未来灵活性"实现功能会浪费时间，增加复杂性。
要点
- 不要为假设的未来需求构建灵活性
- 在需要时实现，而不是之前
- 简单设计胜过预测未来需求的复杂设计
起源
- 源自极限编程 (XP) 方法论
- 由 Kent Beck 在《极限编程解释》(1999)中推广
6.2 DRY (不要重复自己)
"Every piece of knowledge must have a single, unambiguous, authoritative representation."
详细解释
DRY (Don't Repeat Yourself) 的想法很简单：系统中每个事实或逻辑应该只表达一次。如果你在多个模块中发现相同的代码、公式或规则，你就违反了 DRY。
要点
- 避免代码重复
- 抽象共同逻辑到函数或类
- 合并配置到单个文件
起源
- 由 Andy Hunt 和 Dave Thomas 在《程序员修炼之道》中推广
6.3 KISS (保持简单)
"Designs and systems should be as simple as possible."
详细解释
KISS (Keep It Simple, Stupid) 原则指出设计和系统应该尽可能简单。简单性更容易维护、更容易理解、更少出错。复杂性是软件失败的根源。
要点
- 简单是可靠性的先决条件
- 避免不必要的复杂性
- 简单解决方案更容易维护
起源
6.4 SOLID 原则 (SOLID Principles)
"Five main guidelines that enhance software design, making code more maintainable and scalable."
详细解释
SOLID 原则 (SOLID Principles) 是面向对象设计的五个高级指南：
- 单一职责原则 (SRP / Single Responsibility Principle)：每个类只有一个关注点
- 开闭原则 (OCP / Open-Closed Principle)：对扩展开放，对修改关闭
- 里氏替换原则 (LSP / Liskov Substitution Principle)：子类必须可以替换其父类
- 接口隔离原则 (ISP / Interface Segregation Principle)：不强制依赖不使用的接口
- 依赖倒置原则 (DIP / Dependency Inversion Principle)：依赖抽象，不依赖具体
要点
- 当一起应用时，这些原则产生模块化、可扩展和健壮的系统
- 代码更容易测试、重构和扩展
起源
6.5 得墨忒耳定律 (Law of Demeter)
"An object should only interact with its immediate friends, not strangers."
详细解释
得墨忒耳定律 (Law of Demeter) 也称为"不要和陌生人说话"或最小知识原则 (Principle of Least Knowledge)，是为了最小化任何给定对象对整体系统结构的知识。
要点
- 促进松耦合 (Loose Coupling)
- 避免"链式调用"
- 每个组件保持更自包含
起源
- 在 1980 年代 Northeastern University 的研究中制定
6.6 最小惊讶原则 (Principle of Least Astonishment)
"Software and interfaces should behave in a way that least surprises users and other developers."
详细解释
最小惊讶原则 (Principle of Least Astonishment / POLA) 指出软件和界面应该以最不惊讶用户和其他开发者的方式行为。这意味着设计应该遵循约定和期望，而不是创造意外。
要点
- 遵循约定和习惯用法
- 避免意外的副作用
- 一致性是关键
7. 决策 (Decisions)
7.1 邓宁-克鲁格效应 (Dunning-Kruger Effect)
"The less you know about something, the more confident you tend to be."
详细解释
邓宁-克鲁格效应 (Dunning-Kruger Effect) 解释了一个能力和信心之间的差距。当人们对一个领域知之甚少时，他们缺乏判断自己能力所需的意识。结果，他们高估了自己对问题的理解程度。
要点
- 新开发者经常给出自信、精确的估计
- 经验丰富的开发者给出范围（著名的"这取决于"答案）
- 也要注意冒名顶替综合症 (Impostor Syndrome)
起源
- 由 David Dunning 和 Justin Kruger 研究
7.2 汉隆剃刀 (Hanlon's Razor)
"Never attribute to malice that which is adequately explained by stupidity or carelessness."
详细解释
汉隆剃刀 (Hanlon's Razor) 是一个思维模型，建议在可以用愚蠢或粗心充分解释的情况下，不要归因于恶意。
要点
起源
7.3 奥卡姆剃刀 (Occam's Razor)
"The simplest explanation is often the most accurate one."
详细解释
奥卡姆剃刀 (Occam's Razor) 指出，最简单的解释往往是最准确的。在软件中，这意味着选择最简单的解决方案，除非有明确的理由需要复杂性。
要点
- 在复杂性之前尝试简单解决方案
- 避免不必要的假设
- "如无必要，勿增实体"
起源
7.4 沉没成本谬误 (Sunk Cost Fallacy)
"Sticking with a choice because you've invested time or energy in it, even when walking away helps you."
详细解释
沉没成本谬误 (Sunk Cost Fallacy) 是指因为你已经投入了时间或精力而坚持一个选择，即使离开对你有帮助。
要点
- 基于未来价值而非过去投资做决定
- 接受放弃失败的项目
- "及时止损"
起源
7.5 地图不是领土 (The Map Is Not the Territory)
"Our representations of reality are not the same as reality itself."
详细解释
地图不是领土 (The Map Is Not the Territory) 指出我们对现实的表征与现实本身不同。在软件中，这意味着模型、图表和文档不是实际系统。
要点
起源
7.6 确认偏误 (Confirmation Bias)
"A tendency to favor information that supports our existing beliefs or ideas."
详细解释
确认偏误 (Confirmation Bias) 是一种倾向于支持我们现有信念或想法的信息的倾向。
要点
起源
7.7 炒作周期与阿玛拉定律 (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."
详细解释
炒作周期 (The Hype Cycle) 描述了人们对新技术的期望如何随时间变化：最初是"期望膨胀的峰值"，然后是"幻灭的低谷"，然后是"启蒙的斜坡"，最后是"生产力的高原"。阿玛拉定律 (Amara's Law) 总结了这一点。
要点
起源
- 由 Roy Amara 提出
- 由 Gartner 推广为炒作周期
7.8 林迪效应 (The Lindy Effect)
"The longer something has been in use, the more likely it is to continue being used."
详细解释
林迪效应 (The Lindy Effect) 指出，某物使用时间越长，它继续被使用的可能性就越大。在软件中，这意味着老技术往往比新技术更持久。
要点
7.9 第一性原理思维 (First Principles Thinking)
"Breaking a complex problem into its most basic blocks and then building up from there."
详细解释
第一性原理思维 (First Principles Thinking) 是一种将复杂问题分解为其最基本组成部分然后从那里构建的方法。
要点
起源
7.10 反转 (Inversion)
"Solving a problem by considering the opposite outcome and working backward from it."
详细解释
反转 (Inversion) 是一种通过考虑相反结果然后从中倒推来解决问题的方法。
要点
起源
7.11 帕累托原则 (Pareto Principle)
"80% of the problems result from 20% of the causes."
详细解释
帕累托原则 (Pareto Principle) 也称为80/20 法则 (80/20 Rule)，更多是一个观察而不是定律，但 80/20 模式经常出现。在软件工程领域，我们说"80% 的时间花在 20% 的代码上"。
要点
- 识别高影响力问题
- 关注 20% 产生 80% 结果
- 战略性地分配努力
起源
7.12 坎宁安定律 (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."
详细解释
坎宁安定律 (Cunningham's Law) 指出，在互联网上获得正确答案的最好方式不是提问，而是发布错误的答案。
要点
起源
来源：https://lawsofsoftwareengineering.com
在云栈社区，我们相信这些历经时间考验的软件工程定律与思维模型，是每个开发者从优秀走向卓越的必经之路。
发表于 1 小时前
|
查看: 4|
回复: 0
