有哪些编程定律/原则是程序员必须了解的？
前言
在编程开发过程中，有许多定律、理论、原则和模式，这些条条框框并不能能开发人员解决 bug，但却能在无形之中让开发人员少写 bug。
成大事者，嘴边总要碎碎念几句箴言。做人有做人的座右铭，写程序也有写程序的原则理论，心中常念这些定律和模式，除了能让代码变得更加优雅，还能让你在同事眼中更有逼格。
今天要推荐的这个开源项目就总结了对开发人员有用的定律、理论、原则和模式。并且，每一条都附有中文和英文的维基百科链接。
「定律」 ：开发过程中遇到的一些有趣的现象、规律，相信我们所有人都遇到，但是大多数人都没有把这些当回事。严肃地说，如果能事先了解这些定律，不仅能提高逼格，还会省去许多不必要的麻烦。 「原则」 ：介绍了开发过程中需要遵循的各种原则，比较贴近于实际开发的条条框框，有规矩的企业都会严格要求内部代码遵守这些「原则」，其目的都是为了避免不必要的麻烦。
本仓库介绍的定律、原则以及模式，都是为了提高开发者的编程意识，在实际应用中需要灵活使用，「以下内容中，没有任何一条定律或原则是开发人员必须遵守的。」
❝❞
原仓库地址：https://github.com/nusr/hacker-laws-zh 。 中文翻译版地址：https://github.com/nusr/hacker-laws-zh。
下面我将分享一下我对该仓库中提到的一些最最经典、常见的定律和原则的理解。
定律
破窗效应 (The Broken Windows Theory)
❝在破窗理论中认为，一些明显的犯罪迹象(或缺乏环保意识)会导致进一步的、更严重的犯罪(或环境的进一步恶化)。
❞
对应到我们开发中也就是说：劣质代码不优化，会降低后续的开发效率，会进一步让代码质量变得更糟糕。
布鲁克斯法则 (Brooks's Law)
❝软件开发后期，添加人力只会使项目开发得更慢。
❞
嗯……各位组织 leader 一定不要忘了这条法则，在统筹安排开发计划的时候谨慎考虑，因为**“一个人干七天的工作量，真的不能在一天之内，由七个人干完”。**
坎宁汉姆定律 (Cunningham's Law)
❝在网络上想得到正确答案的最好方法不是提问题，而是发布一个错误的答案。
❞
这个定律同样不值得提倡，但是给企业管理人员提供了一种管理思路，也给技术人员提供了一种信息检索的思路。有些时候，「发布一个错误的答案」比「提出一个问题」更能引发大家的激烈讨论。
费茨法则 (Fitts's Law)
❝该法则指出，移动到目标区域所需的时间是到目标的距离除以目标宽度的函数。
费茨法则决定了在设计 UX 或 UI 时，交互元素应该尽可能大，而用户注意力区域和交互元素之间的距离应该尽可能小。这会对设计产生影响，例如将相近的任务进行归类分组等。
同时它还将“魔角 (Magic Corners)”这一概念正式化，即在角落放置关键的 UI 元素，从而使得用户可以通过移动鼠标轻松点击到。Windows 的开始按钮便位于魔角处便于选择，而有趣的是 MacOS 恰恰相反，它的“关闭窗口”按钮 不处于 魔角处，从而能有效减小被误点击的概率。
❞
侯世达定律 (Hofstadter's Law)
❝即使考虑到侯世达定律，它也总是比你预期的要长。
在估计需要多长时间开发时，你可能会听到此定律。软件开发似乎有这样一条定理，即我们往往不能准确地估计需要多长时间才能完成。
❞
该定律和布鲁克斯法则同样都是在描述软件开发后期的种种特性。软件开发和盖楼一样，都是一项需要有长期规划和短期目标的工程，而每到工程的后期，常常会暴露出前中期开发的各种缺陷，到了后期，很有可能举步维艰，一项本来很简单的工作，却牵扯到各个模块，难以解决。因此，每一个短期目标都需要 leader 做精确的安排，各位开发人员也要严格遵守开发文档，免得后期麻烦。
墨菲定律 (Murphy's Law / Sod's Law)
❝凡是可能出错的事就一定会出错。
出自 爱德华·A·墨菲 ， 墨菲定律 说明了如果一件事有可能出错，那么就一定会出错。
❞
嗯……相信大家都听过这句话了，「凡是可能出错的事就一定会出错」，告诫测试人员，不要存有侥幸心理……
奥卡姆剃刀 (Occam's Razor)
❝如无必要，勿增实体。
❞
一个问题可能会有许多解决方案，但根据提出问题的人的需求不同，不同的解决方案的侧重点可能也不同，这时候需要需求人员尽可能地准确地提出自己「更侧重哪方面地需求，哪方面可以妥协」，并在这种权衡下，找到最简单的那个方案。「不要为了其他不是很重要的方面，而把方案变得过于麻烦了。」
原则
鲁棒性原则 (The Robustness Principle or Postel's Law)
❝在自己所做的事情上要保守, 在接受别人的事情上要自由。
❞
鲁棒性原则理念是老生成谈了，该原则有两句话，「对自己保守」和「对他人自由」，说的其实都是鲁棒性这回事。在与其他模块进行交互时，尽量约束自己的信息符合规范，不要挑战其他模块的鲁棒性，给其他人造成麻烦，同时，虽然大家都尽量遵守「对自己保守」的这一原则，可还是难免会有意外地输入，这时候就需要「对他人自由」，要让自己的模块能够容忍来自外部的输入，要同时做到这两点，才能保证系统稳健地运行。
SOLID 原则
「单一责任原则（Single Responsibility Principle）」 ：一个类尽量只负责一种事务的抽象，功能尽量单一，降低耦合。 「开放-封闭原则（Open-Closed Principle）」 ：在类的设计中，要尽量保证“对扩展性的开放，对修改的封闭”。 「Liskov 替换原则（Liskov Substitution Principle）」 ：Liskov 规则严格规定，“子类型必须能够替换其基类型，派生类必须能够通过其基类的接口使用，客户端无需了解二者之间的差异。” 「接口聚合原则（Interface Segregation Principle）」 ：该原则要求，不能强迫客户端依赖于它们不需要的接口，只提供必需的接口。“大”接口尽量分割为若干个”小“接口，不同的接口向不同的客户端提供服务，客户端只访问自己需要的接口。 「依赖转置原则（Dependency Inversion Principle）」 ：抽象的模块不应该依赖于具体的模块，具体应依赖于抽象。
不要重复你自己原则 (The DRY Principle)
❝系统中，每一块知识都必须是单一、明确而权威的。
❞
对于代码来说，DRY 原则可以简单理解为“不要复制粘贴项目已有代码”
KISS 原则 (The KISS Principle)
❝保持简单和直白。
❞
“Keep it simple, stupid”的缩写，也就是保持简单、愚蠢的意思。它告诫我们，对于大多数系统而言，和变得复杂相比，保持简单能够让系统运行得更好。
厚脸皮的来求个赞
Github掘金计划由3位志同道合的Github重度用户维护，我们想让Github 和 Gitee 上优质的开源项目被更多人看到。
每一个项目都是精心筛选而来，文章都是我们利用工作之余的业余时间整理。如果有帮助的话点个在看或者赞就是对我们最大的鼓励！
用心发掘 Github 和 Gitee 上优质的开源项目。欢迎关注！