软件开辟带来了相当多的典范、形式和原则。 其中很多以软件开辟法例的形式出现。

一些软件开辟法例只触及了编码理论。 而别的一些则供给了针对对产物设想和开辟的更普遍方面的看法。 更有些法例超越了这些鸿沟，一样是适用于我们所晓得的生活的形式。

在这里我将先容一些很是重要的软件开辟原则和定律。

1、布鲁克斯法例（Brooks’ law）

Adding manpower to a late project makes it later.

为一个延期的项目增加人力会只会使这个项目更晚。

布鲁克斯法例来自弗雷德~布鲁克斯1975年出书的《人月神话》一书。这触及到一个假定，即团队成员和所需月份是可以交换的。

但究竟并非如此，出格是在软件开辟中（或任何产物开辟中，都是如此）。为什么？由于需要花时候让增加的人力领会并跟上项目标进度。

布鲁克斯法例

2、康威定律（Conway’s law）

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

任何构造在设想一个系统（广义的界说）时，城市发生一个设想，其结构是该构造的相同结构的复制。

Melvin Conway在1967年论述了这一软件开辟的纪律。康威定律与产物设想有关，他观察到构造相同结构对软件输出的影响。

是以，一个合作慎密的团队会建立具有相互交织的功用和代码的软件。 同时，一个更轻松、更分离的团队会建立更多模块化的软件。

康威定律

3、墨菲定律（Murphy’s law）

Anything that can go wrong will go wrong.

凡是能够出错的事一定会出错。

这是本清单中最著名的、最普遍适用的定律。墨菲定律在项目治理、软件开辟和一般生活的各个范畴都能看到。

在软件开辟中，墨菲定律夸大了一个关键点：计较机只能做你告诉（tell）它们做的工作，而不能做你想要（want）他们做的工作。

墨菲定律

4、侯世达定律（Hofstadter’s law）

It always takes longer than you expect, even when you take into account Hofstadter's Law.

它总是比你预期的时候要长，即使你斟酌到了侯世达定律。

“这个工具要花多长时候完成？”是软件开辟中最可怕的题目之一。侯世达定律供给了缘由。它还与另一个定律有关：帕金森定律，该定律以为，在工作可以完成的时限内，工作量会一向增加，直到一切可用时候都被填满为止。

侯世达定律和帕金森定律都说明，几近不成能对工作完成的时候做出切确的估量。

侯世达定律

5、林纳斯定律（Linus’ law）

Given enough eyeballs, all bugs are shallow.

充足多的眼睛，便可让一切题目显现。

只要有充足的测试职员及开辟职员，一切题目城市在很短时候内被发现，而且可以很轻易被处理。

Linus提醒了开辟中的团队合作的重要代价。凡是，在处理题目时，两小我的脑壳比一小我的好。

林纳斯定律

6、古德哈特定律（Goodhart’s law）

When a measure becomes a target, it ceases to be a good measure.

当一个目标成为方针时，它就不再是一个好的目标。

古德哈特定律在软件开辟中的一个例子就是代码行数。代码行数供给了一种权衡软件产物范围的目标。可是，假如被看成方针时，代码质量就会下降。

本应需要精炼或删除的代码行，却被加了进去，构成紊乱的意大利面条式代码。

别的的例子诸如：功用完成数目、bug数目等等。

三聚氰胺进步卵白质浓度，能否是古德哈特定律的活泼例子？

7、盖尔定律（Gall’s law）

A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.

一个能工作的复杂系统是从一个能工作的简单系统演变而来的。一个重新起头建立的复杂系统是不会工作。

我们在很多复杂系统的生命周期中看到了这一点，例如，生命自己从简单的单细胞生物体起头。软件开辟也不破例。

盖尔定律，是一个很好的来由，让我们以最小可行产物（MVP）来停止新的软件产物的开辟。当我们建立一个新的软件产物时，我们应当从一些简单的、有用的工具起头，然后会渐渐演酿成一个更复杂的处理计划。

盖尔定律

8、扎温斯基定律（Zawinski’s Law）

Every program attempts to expand until it can read mail. Those programs which cannot expand are replaced by ones that can.

每个法式都试图扩大，直到它可以读取邮件。那些不能扩大的法式会被能扩大的法式所取代。

说到复杂性，扎温斯基定律表白，产物一旦建成，就会继续扩大。它们会增加更多的功用地区，直到它们没法再扩大。扎温斯基定律，凡是用来对臃肿软件的批评。

功用蠕变（feature creep）的例子说了然软件开辟中的扎温斯基定律。臃肿的法式很快就会被放弃，转而挑选更精简的计划。

扎温斯基定律

9、伊格尔森定律（Eagleson’s law）

Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.

你自己的任何代码，假如你有6个月或更长时候没有看，就似乎是他人写的一样。

很多人以为Eagleson是个悲观主义者，以为6个月是一个悲观的时候，能够要不了6个月。不管怎样说，Eagleson定律夸大了清楚、有用的正文和明白的编码标准的需要性。究竟，即使是最初的法式员也没法在今后的工作中了解自己刚起头编写的紊乱代码。

伊格尔森定律

10、卢巴斯基法例（Lubarsky’s law）

There’s always one more bug.

总会有一个更多的bug。

就算你应用了一切的最好编程理论、更新以及保护，但总是会有一个更多的毛病需要修复。大概还有一件事需要调剂，或增加，或进修。究竟，法式员的工作是永久不会完成的。

是以，请记着，当触及到软件开辟时，完成总比完善好。

卢巴斯基法例

11、克努特优化原则（Knuth’s Optimization Principle）

Premature optimization is the root of all evil.

过早优化是万恶之源。

过早优化让你在你并不真正需要的工具上花费大量的时候。实在的题目是法式员在毛病的时候和毛病的地方花了太多时候来担忧效力效力题目。

假如我们试图优化太早太多，我们就会花大量时候去实现这些优化，从而挤压我们需要实现的方针的时候。我们能够会花太多的时候来实现我们今朝的工具，而未来能够会更糟糕，由于我们挑选的代码不是最轻易保护的。

克努特优化原则

12、伯斯塔尔法例（Postel’s Law）

Be conservative in what you do, be liberal in what you accept from others.

对于自己输出要严酷; 对于他人的输入要灵活。

在开辟一个库、一个HTTP API、一个类、一个模块或一个函数时，我们应当供给向后的兼容性，并对接收的参数变得加倍灵活。这条法则在现实生活中也一样适用--我们应当对自己守旧，但对他人自在/宽大。

伯斯塔尔法例

13、复杂度守恒定律（Tesler’s Law of Conservation as Complexity）

Every APPlication has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.

每个利用法式都有其固有的复杂性，这些复杂性是不能被消除或隐藏的。相反，它必须被处置，不管是在产物开辟中还是在用户互动中。

复杂度守恒定律

14、奥卡姆剃刀道理（Occam’s Razor）

The simplest solution is most likely the right one.

最简单的处理计划极能够是正确的。

更多请参考：《奥卡姆剃刀道理、简单性原则与软件开辟》

奥卡姆剃刀道理

15、软件工作量预算5法例（The 5 laws of software estimates）

1. 预算是浪费时候
2. 预算是不成让渡的
3. 预算是毛病的
4. 预算是临时的
5. 预算是需要的

这是看似冲突法例，但第一条法例说花在预算上的时候不会带来任何新的功用，所以我们不能花太多时候在这上面。但是，第五条法则说它们只是需要的，所以我们应当预算一切的使命，但不要在估量上花太多的时候。

软件工作量预算5法例