对开发人员有用的定律和原则

这篇文章包含对一些定律、原则以及模式的解释，但不提倡其中任何一个。它们的应用始终存在着争论，并且很大程度上取决于你正在做什么。

一、定律

1、布鲁克斯法则

这个定律表明，在许多情况下，试图通过增加人力来加速已延期项目的交付，将会使项目交付得更晚。

布鲁克斯也明白，这是一种过度简化。但一般的论据是，新资源的时间增加和通信开销，会在短期内使开发速度减慢。而且，许多任务是密不可分的，换句话说，这样可以使更多的资源之间能轻易分配，这也意味着潜在的速度增长也更低。

谚语九个女人不能在一个月内生一个孩子与布鲁克斯法则同出一辙，特别是某些不可分割或者并行的工作。

2、坎宁汉姆定律

在网络上想得到正确答案的最好方法不是提问题，而是发布一个错误的答案。

3、邓巴数字

和人与人之间稳定的关系一样，开发人员与代码库的关系也需要努力维护。当面对大型、复杂的项目，或许多项目的归属权时，我们会依赖于约定、策略和建模过程来进行扩展。邓巴数字不仅在办公室规模的扩大的过程中举足轻重，而且在设置团队工作范围，或决定系统何时应该注重于辅助建模和组织管理开销自动化的工具时，也是非常重要的。

4、盖尔定律

一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行，无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。

5、技术成熟度曲线

我们倾向于过高估计技术在短期内的影响，并低估长期效应。

6、墨菲定律

凡是可能出错的事就一定会出错。另外一种说法是，如果某件事可能出错，那么它一定会在最糟糕的时候发生。

7、帕金森定理

为了在规定时间内完成工作，工作将增多，花费比预期更长的时间。

8、过早优化效应

程序员们浪费了大量的时间去思考或者担心他们的程序中的非关键部分的速度。而在考虑调试和维护的时候，这些所谓提高效率的做法实际上十分不妥。我们应该放弃小的效率点，并且要在 97% 的时间提醒自己，过早优化是万恶之源。而且连那关键的 3% 也不能够放过。

9、复杂性守恒定律

系统中的某些复杂性是无意的。这是由于结构不良，错误或者糟糕的建模造成的。这种无意的复杂性可以减少或者消除。然而，由于待解决问题固有的复杂性，某些复杂性是内在的。这种复杂性可以转移，但不能消除。该定律有趣的一点是，即使简化整个系统，内在的复杂性也不会降低。它会转移到用户，并且用户必须以更复杂的方式行事。

10、抽象泄漏定律

过度依赖抽象，加上对底层过程的理解不足，实际上使得问题在某些情况下更加复杂。比如，Linux 操作系统允许通过网络访问文件，但在本地表示为普通文件。如果存在网络故障，这种抽象将会泄漏。如果开发人员将这些文件视为普通文件，而不考虑它们可能会受到网络延迟和故障的影响，那么解决方案就会出错。

11、Unix 哲学

软件组件应该很小，并专注于做一件特定的事情。将小而简单以及定义良好的单元组合在一起，而不是使用大而复杂的多用途程序，可以更轻松地构建系统。

二、原则

1、帕累托法则

帕累托法则可以帮你认识到大多数结果来自少数投入：20％的努力产生了 80％的结果、20％的错误导致了 80％的崩溃。

2、鲁棒性原则

该原则的目标是构建稳健的系统。如果可以理解意图，它们可以处理不良的输入。但是，接受错误格式的输入可能存在安全隐患，特别是此类的输入未经过充分测试。总之，记住在自己所做的事情上要保守, 在接受别人的事情上要自由。

3、SOLID原则

单一功能原则。这意味着对程序功能的单个小更改，应该只需要更改一个组件。开闭原则。实体应开放扩展并关闭修改。里氏替换原则。可以在不破坏系统的情况下，用子类型替换类型。接口隔离原则。不应强制任何客户端依赖于它不使用的方法。依赖反转原则。高级模块不应该依赖于低级实现。

4、不要重复你自己原则

系统中，每一块知识都必须是单一、明确而权威的。

5、KISS 原则

如果大多数的系统能够保持简单而非复杂化，那么他们便能够工作在最佳状态。因此，简单性应该是设计时的关键指标，同时也要避免不必要的复杂度。

6、你不需要它原则

只有当你需要某些东西的时候，才去实现它们，而不是在你预见的时候。

7、分布式计算的谬论

又称网络计算的谬误，这是一系列关于分布式计算的猜想（或者看法），这些猜想可能会引起软件开发中的失败。这些假设是：网络可靠、延迟为零、带宽无限、网络安全、拓扑恒定、有管理员、运输成本为零、网络为同构的。