八个软件工程师需要了解的定理法则

今天我就来介绍几个软件工程师需要了解的定理法则吧。

想到哪里说哪里，是我以前阅读各个技术文章摘录的。

第一个，康威定理！

康威定理

组织设计的系统会映射其自身的沟通结构。《人月神话》。

什么意思呢？比如说你的公司，如果内部，像一个个孤岛一样，那么最终你们的软件，内部也会像一个个孤岛一样的模块。换言之，你的软件的架构结构，和你们的团队开发运作方式是一致的。哈哈，字如其人！

因此，如果你们要达成一个好的软件架构，那就得先把团队搞好。比如微服务，就得先把团队建设成小而分散的规模，单体架构这使用集中办公的形式。

过早优化是万恶之源

正文：性能提升往往伴随着复杂度增加。在尚未明确性能瓶颈所在时贸然应用这种权衡，最终只会导致系统难以理解。

什么意思呢？开发初期，重点要放在清晰的设计上，而不是优化，你还不知道哪些代码是关键的、是性能瓶颈，因此你会很容易浪费很多时间在不关键的代码上。

20%的代码消耗80%的执行时间，你优化另外的不这样的代码，不仅没意义，而且还徒增风险。先让程序跑起来，再让它正确。

海勒姆定律

维基百科的原解释很让人迷糊，我捋了捋，其实意思就是，如果你的软件用的人多，那么一些 bug 其实会变成 feature 哈哈，懂了吧！

所以说，如果你的用户很多，那么做出任何变更，都会对一些人造成潜在的伤害。

很像那个微软，windows ，生态巨大，维护者自作「聪明」不断修复 bug ，从而导致很多新软件崩溃不兼容... 为了保证兼容，微软又恢复保留了古老的 bug。

童子军规则

让代码比你发现时更整洁。

意思就是说，开发时要养成习惯，如果发现有一些代码能优化，那就顺手优化一下，让代码干净一点。日积月累，会产生惊人的效果。

“让营地比你发现时更干净”这句箴言源自美国童子军及全球各地的童军组织。

持续的小改进可以随着时间的推移改变代码库。

你不需要它 定理

只要功能不是必要的，就别加。

换句官方的话，就是预判未来需求往往会导致过度设计，从而增加复杂性和维护问题。

就跟我们小时候计划我们的周末等假期一样，写一大堆东西，最后不切实际，扔掉了。

你现在正在写 A 模块，突然脑袋里想，未来可能有个 B ，会需要 A 做 xxx ，要不要搞个钩子？？？

不要这样！因为未来不一定会这样，过度工程化肯定是错的。用国内的古话就是，画蛇添足！

一口吃不成胖子，迭代开发、迭代开发，与时俱进，与时俱进。

布鲁克斯定律

一个进度落后的项目。人越多，那么会让项目更落后。

换言之，就是要警惕、注意以「多招程序员」作为解决项目延期的方案。

因为新人需要时间熟悉工作，会消耗团队成员的时间，降低生产力。

起源于 IBM 的 布鲁克斯 的经验：你不能通过让九位女性同时怀孕，就指望一个月内生出孩子。12名程序员一个月能完成一名程序员12个月的工作量这一假设，在软件开发中行不通。

高尔定律

一个可运行的复杂系统，总是从一个简单系统演变而来的。

从头开始设计一个复杂系统，永远不会奏效，必须从一个简单系统开始设计。

这就是 AI 时代的小白，不懂编程，怎么也搞不出来一个能跑的软件的最大原因！他们不知道软件开发是一点点写的，直接把需求一股脑模模糊糊的写给 ai，然后跑不动。

我们搞开发也是。应该先做出一个能运行的简单版本，然后迭代并逐步增加复杂性。

完全从头设计的复杂系统通常会失败，因为你无法预见所有的交互关系。这也是为什么我们创业项目都先搞 MVP 。

Facebook最初只是为哈佛学生设计的一个简单网站。如果马克·扎克伯格在 2004 年就试图从零构建 2026 年的 Facebook，它几乎肯定会因自身的复杂性而崩溃。

抽象泄漏定律

所有抽象的模型，都有漏洞！

老外有谚语「抽象没有免费午餐」。只要你为了解决一个问题，抽象了一个概念，试图隐藏复杂性。那它肯定有失效的场景。

比如 Java Python 抽象了内存管理，避免手动内存分配。但是依然会有一些时候会内存泄漏。

比如 HTTP 是互联网里一些概念抽象了一下，搞的这个「很快的请求」概念。但是延迟大了、数据包掉了，这个概念就不是这样了。

反正就是这个意思，使用高级工具，我们依然得了解一下底层运作机制。抽象不是完美的，我们得知道它的本质是啥。