有哪些编程定律/原则是程序员必须了解的？
在编程开发过程中，有许多定律、理论、原则和模式，这些条条框框并不能能开发人员解决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） ：抽象的模块不应该依赖于具体的模块，具体应依赖于抽象。
DRY 原则 (不要重复你自己)
系统中，每一块知识都必须是单一、明确而权威的。
对于代码来说，DRY 原则可以简单理解为“不要复制粘贴项目已有代码”
KISS 原则 (The KISS Principle)
保持简单和直白。
“Keep it simple, stupid”的缩写，也就是保持简单、愚蠢的意思。它告诫我们，对于大多数系统而言，和变得复杂相比，保持简单能够让系统运行得更好。
YAGNI 原则 (你不需要它原则)
这是 You Aren't Gonna Need It 的缩写。只有当你需要某些东西的时候，才去实现它们，而不是在你预见的时候。
极限编程原则告诫开发人员，他们应该只实现当前所需的功能，并避免实现未来需要的功能，仅在必要时才实现。
遵守这一原则可以减小代码库大小，同时避免时间和生产力浪费在没有价值的功能上。
推荐
用心发掘优质开源项目，欢迎关注，欢迎点赞分享！
历史优质开源项目推荐地址：Github 掘金计划。