本文列出了10条经常被忽视的软件工程法则，包括康威定律、布鲁克斯定律、扎温斯基定律、帕金森定律、帕累托法则、斯特金的启示、彼得原理、Eagleson 定律、Greenspun 的第十条编程规则以及冰山谬论。

在进行软件开发和产品设计的时候，有一些经典又有重要参考价值的法则常常被忽视，而忽视这些法则又会让开发者走一些弯路。

因此，小编在这里放上10条最容易被忽视的10条软件工程法则，大家可以作为参考：

1. 康威定律（Conway's Law）

任何设计系统的组织，其设计的结构都是该组织沟通结构的复制品。

你可能会认为，通过不同层级的会议以及股东的更新和决策，这个状况可以得到避免，但是实际是，冲突或分歧发生的优先级，将导致同样冲突和分歧的过程和结果，从而影响整个设计的结构。

2. 布鲁克定律（Brooks's Law）

“给一个迟来的软件项目增加人力会使它更迟。”

当你意识到你没有取得预期的进展，并且管理层试图重新分配人力资源时，那么项目不仅会更加推迟，而且最后很可能会交付一个更加脆弱、更复杂的产品。

3. 扎温斯基定律（Zawinski's Law）

“每个程序都试图扩展，直到它包含了一个web服务器。那些不能扩展的项目会被能够扩展的项目所取代。”

4. 帕金森定律（Parkinson's Law）

工作完成的时间会影响工作的量"

在这里，主要的项目管理经验是，如果你不为概念性的里程碑设定大概的最后期限，那么项目将永远不会完成。这也说明了在固定的时间线上迭代最小可行产品的重要性。

当然，我们也可以根据数据、处理能力、RAM等等来调整这条法则:

在使用完所有可用的存储空间/带宽/周期/RAM之前，数据/CPU/内存的使用会一直扩展

实际上，32GB对任何人来说都足够了，对吧?

5. 帕累托谬论（Pareto's Fallacy）

帕累托原则很容易被曲解，尤其是被管理层曲解。这通常会导致帕累托谬论:

“当你完成了80%时，你会认为你只剩下20%了。”

这里忽略的关键部分是，这20%，其实需要你投入80%的时间。

6. 斯特金启示（Sturgeon's Revelation）

所有部分的90%都是无用的。

是的，你的产品也包含在内。

7. 彼得原则（The Peter Principle）

在等级制度中，每个员工都倾向于升到他们不能胜任的级别。因此，随着时间的推移，每个岗位都有可能被不称职的员工占据。”

8. Eagleson定律（Eagleson's Law）

任何你自己的代码，如果你有6个月或更长的时间没有查看，就好像是别人写的一样。

实际上，6个月已经相当乐观了。

不过，有一点需要注意，那就是“Yo mom推论”:

只有原作者才可以批评代码;任何其他的负面反馈都会被驳回。

9. Greenspun编程的第10条规则（Greenspun's 10th Rule of Programming）

任何自定义开发的身份验证系统都包含一个特别的、非正式指定的、充满错误的、缓慢的Kerberos实现。

这可以概括为普遍的NIH规则:“任何定制开发的系统都包含一个临时的、非正式指定的、有bug的、缓慢的执行，而这些执行的对象有一半都是你拒绝使用的工业界标准。”

10. 冰山谬论（The Iceberg Fallacy）

新软件产品的开发成本仅占所有权管理的总成本和预算的25%。

对于运维来说，有一句格言是这么说的：

“如果软件维护占总拥有成本的75%，那么运营支持就是剩下的75%。