程序员除了要会写代码，还要懂得职场的15大定律和7大原则-电子发烧友网

作一个优秀的程序员，除了要会写代码，还要懂得职场的15大定律和7大原则。昨日，GitHub趋势榜第一的项目便总结了这些定律和原则。总有一款适合你。

总有一款适合你。

作为程序员，你除了会敲代码，还得知晓属于你的定律。今日GitHub便有一个项目总结了与开发人员相关的15大定律和7大原则。

项目地址：

https://github.com/dwmkerr/hacker-laws

该项目目录如下：

简介

定律

阿姆达尔定律(Amdahl's Law)

布鲁克定律(Brooks's Law)

康威定律(Conway's Law)

侯世达定律(Hofstad ter'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模型还普及了部落、公会、分会等组织结构的其它组成部分。