Repo 💻📖 hacker-laws
定律
1. 阿姆达尔定律
向执行程序的系统添加多个处理器只能获得有限的好处，它可以极大地提升并行程序的速度，串行部分的速度将保持不变。
2. 布鲁克斯法则
软件开发后期，添加人力只会是项目开发得更慢。
无论多少个女人，孕育一个生命也需要九个月。
3. 康威定律
软件架构反映了组织结构。
4. 侯世达定律
做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。
5. 技术成熟度曲线
我们倾向于过高估计技术在短期内的影响，并低估长期效应。
6. 隐式接口定律
你在合同中的承诺并不重要： 你系统的所有可观察行为将取决于其他人。
应该是指：即使你某些方法仅限内部使用，但仍然会有些人将这些方法用于外部调用
7. 摩尔定律
集成电路中的晶体管数量大约每两年翻一番。
8. 帕金森定理
在工作能够完成的时限内，工作量会一直增加，直到所有可用时间都被填满为止。
9. 普特定律
技术由两类人主导，一类是纯粹的管理人员， 一类是纯粹的技术人员。
没太看明白，是指技术领导长期不接触一线代码导致技术能力下降吗？
10. 复杂性守恒定律
系统中存在着一定程度的复杂性，并且不能减少。
11. 漏洞抽象定律
在某种程度上，所有非平凡的抽象都是漏洞。
定义太拗口了，直接看例子吧。
我过去遇到过一个问题，就是 Photoshop 启动缓慢，有时需要几分钟。问题好像是 Photoshop 启动时，会读取当前默认打印机的一些信息。但是，如果该打印机实际上是一台网络打印机，则可能需要很长的时间。将网络打印机与本地打印机当作同样的抽象，导致连接不良的情况下出现问题。
12. 帕金森琐碎定理
群体将给予更多的时间和注意力来处理琐碎的问题，而不是用来处理严肃而实质性的问题。
常见的虚构例子是委员会批准核电站的计划，他们大部分时间都在讨论自行车棚的结构，而不是电厂本身等更为重要的设计。
13. Unix 哲学
做一件事，做好它。将小而简单以及定义良好的单元组合在一起，而不是使用大而复杂的多用途程序，可以更轻松地构建系统。
- 小即是美
- 让程序只做好一件事
- 尽可能早地建立原型
- 可移植性比效率更重要
- 数据应该保存为文本文件
- 尽可能地榨取软件的全部价值
- 使用shell脚本来提高效率和可移植性
- 避免使用可定制性低下的用户界面
- 所有程序都是数据的过滤器
14. Spotify 模型
团队围绕功能而非技术进行组织。
原则
1. 鲁棒性原则
在自己所做的事情上要保守, 在接受别人的事情上要自由。
通常应用于服务器应用程序开发中，该原则指出，你发送给其他人的内容应尽可能最小且符合要求，并且处理不符合要求的输入。
2. SOLID
- S：单一功能原则 (The Single Responsibility Principle)
- O：开闭原则 (The Open/Closed Principle)
- L：里氏替换原则 (The Liskov Substitution Principle)
- I：接口隔离原则 (The Interface Segregation Principle)
- D：依赖反转原则 (The Dependency Inversion Principle)
2.1 单一功能原则
每个模块或者类只应该有一项功能。
理论上讲，这使代码更健壮，更容易更改。知道正在更改的组件只有一个功能，这意味着测试更改更容易。
2.2 开闭原则
软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的，这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。
2.3 里氏替换原则
子类对象可以在程式中代替其基类（超类）对象
2.4 接口隔离原则
接口应提供给客户端仅需必需信息。
接口隔离原则(ISP)拆分非常庞大臃肿的接口成为更小的和更具体的接口，这样客户将会只需要知道他们需要的方法。接口隔离原则的目的是系统解开耦合，从而容易重构，更改和重新部署。
2.5 依赖反转原则
高层次的模块不应该依赖于低层次的模块，两者均应依赖于抽象接口。
抽象接口不应依赖于具体实现，而应具体实现依赖于抽象接口
3. DRY
系统中，每一块知识都必须是单一、明确而权威的。
这个原则旨在帮助开发人员减少代码的重复性，并将公共代码保存在一个地方。
