IT行业经典定律
一、问题认知
XY 问题：不问真正的问题 X，反而问自拟的解决方案 Y，导致更优路径被忽略。
例子：业务老师希望批量得到客户纸质表单上的几个信息（X），跑去问开发团队如何批量识别纸质表单上的数据并导出CSV文件（Y），其实这几个信息数据库都有记录。
二八法则（帕累托法则）：80% 的结果由 20% 的原因产生。
例子：一个项目中20%的代码，撑起最长用的80%功能。
吉尔布定律（Gilb’s Law）：任何能够被测量的东西，都能够被改进。
例子：你开始记录每天写代码的专注时长，仅仅因为”在记录”，你就会不自觉地更加专注，效率真的提升了。
幂律分布（Power Law）：少数节点拥有绝大多数连接，其余节点连接极少。
例子：互联网流量里，头部 1% 的网站吃掉了 90% 的访问量；长尾那 99% 的网站加起来才分 10%。
自行车棚效应：人们对简单琐碎的问题反而投入过多讨论时间，对复杂核心问题却轻易放过。
例子：技术评审会上，复杂的分布式架构方案半小时就通过了，却为按钮颜色、接口命名风格争论了一个小时。
沃克定律（Wadler’s Law）：在编程语言设计中，讨论语法所花的时间与其重要性成反比——越是无关紧要的语法细节，争论越久。
例子：语言设计委员会开了三个月会，其中两个月在吵缩进到底用 Tab 还是空格，真正的核心类型系统只聊了一下午。
汉隆剃刀定律：能解释为疏忽的问题，就不要归因为恶意。
例子：线上出现接口调用异常，优先排查参数传错、文档遗漏等疏忽问题，不要先假定是对方团队故意为之。
坎宁汉定律（Cunningham’s Law）：在互联网上想得到正确答案的最好方法，不是提问，而是发布一个错误的答案。
例子：你在技术论坛发帖”Python 肯定没有 GIL 吧？”——十分钟内就会有八个老哥跳出来把你纠正一遍，顺便把原理讲透。
二、风险管理
墨菲定律：凡是可能出错的事情，就一定会出错。（而且经常在最不能承受的时候发生）
例子：某直播平台，发现直播推流接口只判断了Token没再次去鉴权，为了兼容旧接口一再推迟上线时间。最后被黑客组织利用，导致近年来最大的直播事故。
演示定律：每当你当众演示系统时，它大概率会出故障。
例子：本地和测试环境跑了几十次都正常的功能，给客户现场演示时刚好触发边界条件直接闪退。
海因里希法则：每 1 起严重事故背后，对应 29 起轻微事故与 300 起未遂隐患。
例子：出现 1 次线上 P0 级数据故障，往前排查能发现 29 次线上小异常告警，以及 300 次被忽略的代码不规范和测试用例缺失。但实际情况是大家经常把这些小问题忽视了。
三、项目管理
霍夫施塔特定律：做事耗时总比预期长，即便你已经考虑了这条定律本身。
例子：你预估需求开发要 2 周，特意多预留了 3 天缓冲时间，最终还是因为需求变更、联调卡点超期了。
计划谬误定律：人们总会低估任务耗时，即便有过往经验也难以避免。
例子：你评估一个简单表单开发只需要 3 天，实际对接接口、处理兼容、改需求加校验，最后花了整整一周才上线。
帕金森定律：工作会自动膨胀，直至填满所有可用时间。
例子：原本 2 周就能做完的需求，给了 1 个月的排期，最后真的会拖到截止日前两三天才集中完成。
功能膨胀定律：系统一旦开放扩展，功能会持续增生直至臃肿，必须主动设界。
例子：在IE时代，所有人都觉得IE很慢。于是微软内部有团队用开源引擎重新开发了一个新版浏览器，一开始效果很好，但随着对IE各种功能兼容的越来越多，这个浏览器变得比IE还慢而且经常崩溃，最后这个项目被砍了。后来做Edge的时候，很多IE的功能是不兼容的，扔掉了旧包袱，让Edge比IE好用的多。
90-90 法则：软件开发前 90% 的功能耗费 90% 的工期，剩下 10% 的收尾工作也会耗费 90% 的工期。
例子：核心业务逻辑很快开发完成，以为即将上线，结果边界场景兼容、异常处理、性能优化等收尾工作，又花掉了和主开发几乎等量的时间。
克尼汉定律（Kernighan’s Law）：调试一段一开始就写错的代码，比重新写一遍要难一倍。
例子：你从别人手里接了一段绕来绕去的代码，修了 A 处冒出 B 处 Bug；折腾三天后索性推倒重写，半天搞定。
布鲁克斯定律：向已延期的软件项目加人，只会让它完成得更晚。
例子：项目已经延期两周，临时新增 3 名开发加入，老员工需要花大量时间做业务讲解、代码交接和环境搭建，整体进度反而进一步延后。
沉默成本谬误（Sunk Cost Fallacy）：人们倾向于继续投入资源到一个已经失败的项目中，仅仅因为已经投入了很多。
例子：花了两年做的产品根本没市场，团队却说”都做了两年了，放弃太可惜”，又烧了一年钱才彻底关停。
四、系统设计
康威定律：系统的架构必然复刻设计它的组织的沟通结构。
例子：公司业务团队拆分成三条线，各自定业务规则，各自提系统需求。最终做出来的系统就会是底层三套相互割裂的规则，表面上被捆绑在一起。
阿姆达尔定律：并行系统的加速上限，由程序中无法并行的串行部分占比决定。
例子：一个任务 90% 逻辑可多线程并行，10% 必须串行执行，就算开到 100 个线程，整体速度最多也只能提升 10 倍。
例子：一个组织编码工作只占10%，其余90%工作需要串行，哪怕编码工作提升到耗时为0，整体效率也只能提升11%。
泰斯勒定律（复杂性守恒原理）：复杂性不会凭空消失，只会从一处转移到另一处。
例子：把单体系统拆成微服务后，单个服务的业务逻辑变简单了，但服务治理、链路追踪、分布式事务的整体复杂度反而大幅增加。
例子：各类跨平台的框架，开发用的很爽，无需各种适配，一次写完可以编译为各平台的Native程序。因为复杂度被底层框架承接了。
例子：为了赶工期，做了很多硬编码，项目匆匆上线。最后要花更多的时间，重构这些代码。
盖尔定律（Gall’s Law）：一个切实可行的复杂系统，总是从一个切实可行的简单系统演化而来的。
例子：想一步到位做个”完美架构”的微服务系统，往往直接失败；从单体应用起步、随着业务增长逐步拆分，反而能活下来。
伊格尔森定律：自己六个月前写的代码，和别人写的没什么两样，同样看不懂。
例子：回头修改半年前写的工具类代码，因为没写注释、命名随意，自己都要花半天才能理清逻辑，完全看不出是自己写的。
海勒姆定律：API 用户足够多时，其所有可观测行为（含未文档细节）都会被人依赖。
例子：接口文档没声明返回列表的排序规则，但大量下游业务默认按当前顺序处理，后续优化排序逻辑后直接引发大面积业务异常。
死代码悖论：你因为 “以后可能用得到” 而保留的代码，永远不会被真正用到，只会持续增加维护负担。
例子：开发时顺手保留了三套备用实现逻辑没删掉，后续迭代中这些代码既没人用，还经常在重构时引发编译错误和理解成本。
CAP 定理：分布式系统最多只能同时满足一致性、可用性、分区容错性中的两项。
例子：电商下单系统优先保证数据一致性和分区容错，网络分区发生时就会暂停下单操作，牺牲部分可用性。
五、质量管理
沃斯定律：软件变慢的速度，永远快过硬件性能提升的速度。
例子：电脑 CPU 性能相比五年前翻了数倍，但新版 IDE、编辑器的内存占用和启动耗时也同步膨胀，日常使用体感并没有明显提速。
缺陷聚集原则：软件缺陷并非均匀分布，绝大多数集中在少数模块中。
例子：项目中频繁迭代、改动最多的用户认证模块，集中了全系统近 70% 的线上缺陷。
林纳斯定律：足够多的眼睛审视，就能让所有问题浮出水面。
例子：开源项目面向全球开发者开放源码审查，隐藏的深层漏洞往往比闭源项目更快被发现和修复。
破窗效应：不良现象一旦被放任，就会诱使人们效仿甚至变本加厉。
例子：代码里一处没人清理的冗余逻辑和临时写法，很快会让整个模块都充满不规范的代码。
格雷沙姆定律：劣币驱逐良币 —— 当劣质币和优质币同时流通时，人们会囤积优质币、花出劣质币，最终市场上只剩下劣质币。。
例子：项目赶工期时大量临时拼凑的烂代码被合入主干，并被业务方称赞响应及时。好好写代码，重构提升代码质量的开发，被嫌弃响应缓慢。久而久之整洁规范的代码越来越少，代码库整体质量持续下滑。
六、组织管理
古德哈特定律：当一项指标被当作考核目标，它就不再是一个好的衡量指标。
例子：团队把代码行数作为开发工作量考核标准，最终大家疯狂堆砌冗余代码，整体代码质量不升反降。
德西效应（Deci Effect）：过度使用外部奖励反而会削弱内在动机。
例子：孩子本来爱画画，你每次画完给 10 块钱，三个月后不给钱他就不画了——原本的兴趣被”买”没了。
彼得定律（Peter Principle）：在一个等级制度中，每个员工都会晋升到他不能胜任的职位。
例子：顶尖的销售员被提拔成销售总监，结果他不懂管理，团队业绩一路下滑。
呆伯特定律（Dilbert Principle）：公司往往会把最无能的员工提升到管理层，让他们离开一线，从而减少对实际工作的破坏。
例子：那个搞砸了三个项目的老员工，被”升”为中层管理者，从此只开会不干活，反而对公司危害小了。