【新智元导读】作一个精良的程序员，除了要会写代码，还要懂得职场的15大定律和7大原则。昨日，GitHub趋势榜第一的项目便总结了这些定律和原则。总有一款适宜你。
总有一款适宜你。
作为程序员，你除了会敲代码，还得知晓属于你的定律。今日GitHub便有一个项目总结了与开拓职员干系的15大定律和7大原则。
项目地址：
https://github.com/dwmkerr/hacker-laws
该项目目录如下：
简介定律阿姆达尔定律(Amdahl's Law)布鲁克定律(Brooks's Law)康威定律(Conway's Law)侯世达定律(Hofstadter's Law)阿玛拉定律的“炒作周期”(The Hype Cycle & Amara's Law)海勒姆定律(Hyrum's Law)摩尔定律(Moore's Law)帕金森定律(Parkinson's Law)普特定律(Putt's Law)泰斯勒定律(繁芜性守恒定律,Tesler's Law)抽象化漏洞定律(The Law of Leaky Abstractions)噜苏定律(The Law of Triviality)Unix哲学(The Unix Philosophy)Spotify模型(The Spotify Model)Wadler定律(Wadler's Law)原则鲁棒性原则(The Robustness Principle,Postel's Law)SOLID单一职责原则(The Single Responsibility Principle)开放封闭原则(The Open/Closed Principle)李氏更换原则(The Liskov Substitution Principle)接口分离原则(The Interface Segregation Principle)依赖颠倒原则(The Dependency Inversion Principle)TODO那么接下来，我们就对这些定律和原则进行逐一解读。
开拓职员需知的15大定律
阿姆达尔定律(Amdahl's Law)
维基百科中对此定律的解读是：
阿姆达尔定律，一个打算机科学界的履历法则，因吉恩·阿姆达尔而得名。它代表了处理器并走运算之后效率提升的能力。并行打算中的加速比是用并行前的实行速率和并行后的实行速率之最近表示的，它表示了在并行化之后的效率提升情形。阿姆达尔定律是固定负载（打算总量不变时）时的量化标准。此处举个例子来解释：如果一个程序由两部分组成，一部分A(必须由一个处理器实行)和一部分B(可以并行实行)，那么我们可以看到，向实行程序的系统添加多个处理器只能带来有限的好处。它可以极大地提高B部分的速率，但是A部分的速率将保持不变。
下图显示了速率可能改进的一些示例：
可以看出，纵然是一个50%可并行的程序，在超过10个处理单元的情形下也险些没有什么好处，而一个95%可并行的程序，在超过1000个处理单元的情形下，仍旧可以显著提高速率。
随着摩尔定律(Moore’s Law)的放缓，以及单个处理器速率的加速放缓，并行化是提高性能的关键。图形编程是一个很好的例子(利用当代基于着色器的打算，单个像素或片段可以并行呈现)，这便是为什么当代显卡常日有成千上万的处理核心(gpu或着色器单元)。
布鲁克定律(Brooks's Law)
维基百科中对此定律的解读是：
将人力资源添加到一个后期软件开拓项目中会使它更晚。这条定律表明，在许多情形下，试图通过增加更多的人来加速已经晚了的项目，将使交付日期更晚。该定律楚地表明这是一种过度简化，但一样平常的推理是，鉴于新资源的增加韶光和通信开销，在短期内的速率会降落。而且，许多任务可能不是可分的，即随意马虎在更多资源之间分配，这意味着潜在的速率增长也更低。
交付事情中常见的一句话，“九个女人不能在一个月内生孩子”是与布鲁克斯定律有关，特殊是某些事情不可分割或平行的事实。
康威定律(Conway's Law)
维基百科中对此定律的解读是：
这条法律表明，一个别系的技能边界将反响组织的构造。设计系统的组织受限于设计这些组织的通信构造的副本。
这条定律表明，一个别系的技能边界将反响组织的构造。康威定律表明，如果一个组织是由许多小的、不相连的单元组成的，那么它所生产的软件将是如此。如果一个组织更多地环绕功能或做事的“垂直领域”构建，软件系统也会反响出这一点。
侯世达定律(Hofstadter's Law)
维基百科中对此定律的解读是：
纵然考虑了侯世达定律，它也总是比你想象的要花更长的韶光。当你在估计某件事须要多永劫光的时候，你可能听说过这个定律。在软件开拓中，我们每每不善于准确地估计某个东西须要多永劫光才能交付，这彷佛是一个旧调重弹的事实。
阿玛拉定律的“炒作周期”(The Hype Cycle & Amara's Law)
维基百科中对此定律的解读是：
我们方向于过高估计技能在短期内的影响，并低估长期效应。Hype Cycle(炒作周期)是技能随着韶光的推移而产生的愉快和发展的直不雅观表现，最初由Gartner开拓。最好用视觉效果来表现：
简而言之，这一周期表明，人们常日对新技能及其潜在影响感到愉快。团队常常快速地投入到这些技能中，有时会对结果感到失落望。这可能是由于技能还不足成熟，或者现实天下的运用还没有完备实现。经由一段韶光，技能的能力和利用它的实际机会都会增加，团队终极会变得富有成效。罗伊•阿马拉(Roy Amara)的名言最简洁地概括了这一点——“我们每每高估了一项技能的短期效果，而低估了长期效果。”
海勒姆定律(Hyrum's Law)
维基百科中对此定律的解读是：
有足足数目标API用户，您在公约中承诺的并不主要：系统的所有可不雅观察行为都将取决于某人。Hyrum定律指出，当一个API有足够多的消费者时，这个API的所有行为(乃至那些没有被定义为公约的一部分的行为)终极都会被某人所依赖。一个大略的例子可能是非功能元素，比如API的相应韶光。一个更奇妙的例子可能是依赖于对缺点运用正则表达式来确定API缺点类型的消费者。
纵然API的公约没有声明关于内容的任何内容，表明用户该当利用干系的缺点代码，一些用户也可能利用，变动实际上会毁坏这些用户的API。
摩尔定律(Moore's Law)
维基百科中对此定律的解读是：
集成电路中的晶体管数量大约每两年翻一番。摩尔的预测常常被用来解释半导体和芯片技能进步的绝对速率。事实证明，从上世纪70年代到本世纪头十年末，摩尔的预测是非常准确的。近年来，这一趋势发生了轻微的变革，部分缘故原由是对组件小型化程度的物理限定。然而，并行化的进步，以及半导体技能和量子打算领域潜在的革命性变革，可能意味着摩尔定律在未来几十年仍将适用。
帕金森定律(Parkinson's Law)
维基百科中对此定律的解读是：
事情量不断增大，以补充知足事情所需的截止韶光。在其最初的背景下，这个定律是基于对官僚机构的研究。它可能被\公众悲观\"大众地运用于软件开拓操持，理论是团队在截止日期之前效率低下，然后在截止日期前赶紧完成事情，从而使得实际截止日期变得有些随意。
如果将这一定律与侯世达定律结合起来，就会得出一个更加悲观的不雅观点——事情量将会增大，以补充完成它所须要的韶光，而且仍旧比预期的要长。
普特定律(Putt's Law)
维基百科中对此定律的解读是：
技能由两类人主导，一类人懂他们不并须要管理的事务，另一类人管理者他们不懂的事务。普特定律每每遵照普特推理(Putt's Corollary)：
随着韶光的推移，每一个技能层次都会发展出一种能力颠倒。这些陈述表明，由于各种选择标准和群体组织办法的趋势，技能组织的事情层面将有一些技能职员，以及一些不理解繁芜性和寻衅的管理角色的职员。
然而须要强调的是，此类定律是广泛的概括，可能适用于某些类型的组织，而不适用于其他类型的组织。
泰斯勒定律(繁芜性守恒定律,Tesler's Law)
维基百科中对此定律的解读是：
这条定律表明，一个别系中有一定程度的繁芜性是无法降落的。系统中的某些繁芜性是“无意的”。 这是由于构造不良、缺点或者只是办理问题的糟糕建模造成的。 可以减少（或肃清）这种“无意”的繁芜性。然而，一些繁芜性是“内在的”，这是所办理问题内在繁芜性的结果。这种繁芜性可以转移，但不能肃清。
这个定律中一个有趣的点，纵然简化了全体系统，内在的繁芜性也没有减少，而是转移到了用户身上，用户必须以更繁芜的办法行事。
抽象化漏洞定律(The Law of Leaky Abstractions)
维基百科中对此定律的解读是：
在某种程度上，所有非平凡(non-trivial)抽象都是有漏洞的。该定律指出，抽象化(常日用于打算以简化繁芜系统的事情)在某些情形下会“泄露”底层系统的元素，这使得抽象化的行为办法出人意料。
加载文件并读取其内容便是一个例子。文件系统API是较低层内核系统的抽象，内核系统本身是与变动磁盘片(或SSD的闪存)上的数据干系的物理进程的抽象。在大多数情形下，将文件处理为二进制数据流的抽象是可行的。然而，对付磁驱动器，顺序读取数据的速率将明显快于随机访问(由于页面缺点的开销增加)，但是对付SSD驱动器，不会涌现这种开销。处理这种情形须要理解底层细节(例如，数据库索引文件的构造是为了减少随机访问的开销)，开拓职员可能须要理解抽象的“泄露”实现细节。
当引入更多抽象时，上面的示例可能会变得更加繁芜。Linux操作系统许可通过网络访问文件，但在本地表示为“普通”文件。如果存在网络故障，这个抽象将会“泄露”。如果开拓职员将这些文件视为“正常”文件，而没有考虑到它们可能会受到网络延迟和故障的影响，那么办理方案就会有bug。
噜苏定律(The Law of Triviality)
维基百科中对此定律的解读是：
这一定律表明，团体将把更多的韶光和精力放在噜苏或表面征象上，而不是严明和本色性的问题。Unix哲学(The Unix Philosophy)
维基百科中对此定律的解读是：
Unix哲学是软件组件该当很小，并且专注于做好一件特定的事情。通过将小的、大略的、定义良好的单元组合在一起，而不是利用大型的、繁芜的、多用场的程序，可以更随意马虎地构建系统。像“微做事体系构造”这样的当代实践可以被看作是这条定律的一个运用，此处，做事是小的、集中的，并且只做一件特定的事情，许可由大略的构建块组成繁芜的行为。
Spotify模型(The Spotify Model)
维基百科中对此定律的解读是：
Spotify模型是团队和组织构造的一种方法，已被“Spotify”推广。在这个模型中，团队是环绕功能而不是技能来组织的。Spotify模型还遍及了部落、公会、分会等组织构造的其它组成部分。
Wadler定律(Wadler's Law)
维基百科中对此定律的解读是：
在任何措辞设计中，谈论这个列表中某个特性所花费的总韶光与它位置的幂成正比。0.语义1.语法2.词汇语法3.注释的词汇语法类似于“噜苏定律”，Wadler定律指出，在设计一种措辞时，与这些特色的主要性比较，花在措辞构造上的韶光是不成比例的。
七大原则及更多精彩内容请看原文链接：
https://github.com/dwmkerr/hacker-laws