统治软件开发中的著名定律
翻译| 码农翻身
和其他领域一样，在软件开发的世界中也有一些有趣而著名的定律，开发人员、管理人员还是架构师，都经常在会议或闲谈中提到他们，很多时候我们都只是点头附和，免得让人知道自己其实根本没听说过布鲁克斯(Brooks)、摩尔(Moore)或康威(Conway)这些大佬。
在这里，我把这些定律整理出来，分享给大家。
或许是所有的定律中最广为人知的，因为它不仅仅适用于软件开发领域。
凡是可能出错的事就一定会出错。
衍生定律：说脏话是唯一一门程序员用得都很流畅的语言。
推论：计算机会按照你写出来的方式运行，而不是你臆想出来的。
防御性编程、版本控制、测试驱动开发、模型驱动开发等等都是预防墨菲定律很好的做法。
大多数开发人员都会经历过布鲁克斯定律：
向一个延期的项目增加人手只会让它延期得更加厉害
如果一个项目进展落后了，仅仅增加人力很有可能会带来灾难性的后果。
相反，提高编程效率、审查软件开发方法和技术架构是否合理，几乎总是会比增加人力带来更好的效果。如果没有，这可能意味着霍夫施塔特定律在起作用。
霍夫斯塔特定律是由道格拉· 霍夫斯塔特(Douglas Hofstadter) 提出，并且以他的名字来命名的。
不要将这个定律与《生活大爆炸》中的伦纳德·霍夫斯塔特混为一谈。即使他的话对你们一些人或许有用。
这个定律是这么说的：
事情总是要花费比你预想更长的时间，即使你把霍夫斯塔特定律也考虑在内。
这条定律的递归性反映出，即使付出最大的努力，也知道任务是复杂的，去精确地估算它依然是非常难的，所以要给估算留一个缓冲区出来。
软件的任何一部分都反应了创建它的组织结构
或者更清楚一点：
组织形式等同其设计的系统架构
许多组织都根据他们的技能来划分团队。因此会有前端开发、后端开发和数据库开发组成的团队。这会导致某人想要修改一个不属于自己领域的东西会很难。
最好是按照有边界的上下文(bounded context)来规划团队，并且越来越多的组织者也正在这么做。像微服务这样的架构围绕服务边界而不是孤立的技术体系划分来组织他们的团队。
康威定律带来的具体的实践建议就是：你想要什么样的系统设计，就架构什么样的团队，这会带来事半功倍的效果。
又称健壮性法则(Robustness principle)
发送时要保守，接收时要大方
Jon Postel 最初认为正是这个原则让TCP协议的实现很健壮。一些人认为这正是 HTML 很成功的原因，也有一些人认为这正是 HTML 很失败的原因。（因为HTML可以写得不那么严格，但是浏览器依然可以解析它）
又称80/20法则(The 80-20 rule)
对于许多现象来说，有 80% 的后果都是 20% 的原因造成的。
在软件开发中的体现是： 代码中80%的错误都是由代码中的20%引起的。
另外，公司80%的工作是由20%的员工完成的。问题是你并不总是清楚谁是那20%。
该原则还是比较打击人的，特别是你碰巧正在经历的话。
在等级制度中，每个员工都倾向于提升到他无法胜任的等级
在各种组织中，由于习惯于对在某个等级上称职的人员进行晋升提拔，因而雇员总是趋向于被晋升到其不称职的地位。
一旦组织中的相当部分人员被推到了其不称职的级别，就会造成组织的人浮于事，效率低下，导致平庸者出人头地，发展停滞。
在密码学中，即使一个系统中的所有东西都是公开的（密钥除外），该系统也应当是安全的。
这就是非对称加密的主要原则。
以Linux之父林纳斯·托瓦兹（Linus Torvalds）的名字命名，该定律表述为：
众目睽睽之下，一切 bug 都无所遁形
这个定律出自著名的文集《大教堂与集市》，这个文集对比了两种不同的开源软件开发模型。
大教堂模型，每个软件发行版都伴有源代码，但是仅限于软件开发人员查看。
集市模型，以互联网为媒介，代码开发的过程完全暴露在大众的视野下。
被公开审查、测试的代码越多，各种形式的错误就能更快地被发现。
每一美元所能买到的电脑性能，将每隔24个月翻一番。
最流行的版本是：
集成电路上可容纳的元器件的数目，约每隔18个月便会增加一倍。
或
计算机的处理性能每隔两年翻一倍。
前90%的代码要花费10%的开发时间，剩余的10%的代码要再花费90%的开发时间。
如此真实。还会有人不同意吗？
不成熟的优化是万恶之源。
先把代码写出来，定位瓶颈所在，然后优化它。
当公司的市场份额超过50%之后，就不能再翻番了。
这就是我喜欢的“定律”， 他们都有自己的故事和背景。作为软件开发人员你必须熟悉他们。
你也许会赞同或不赞同某条定律，或在其中任何一条有过有趣的经历，欢迎在下方留言讨论！