本文列出了10条常常被无视的软件工程规律，包括康威定律、布鲁克斯定律、扎温斯基定律、帕金森定律、帕累托规律、斯特金的启示、彼得原理、Eagleson 定律、Greenspun 的第十条编程规则以及冰山谬论。
在停止软件开发和产品设计的时分，有一些经典又有重要参考价值的规律常常被无视，而无视这些规律又会让开发者走一些弯路。
因此，小编在这里放上10条最容易被无视的10条软件工程规律，大家可以作为参考：
1. 康威定律（Conway's Law）任何设计系统的组织，其设计的结构都是该组织沟通结构的复制品。
你能够会以为，经过不同层级的会议以及股东的更新和决策，这个状况可以失掉避免，但是实践是，抵触或分歧发作的优先级，将招致异样抵触和分歧的进程和结果，从而影响整个设计的结构。
2. 布鲁克定律（Brooks's Law）“给一个迟来的软件项目添加人力会使它更迟。”
当你看法到你没有取得预期的停顿，并且管理层试图重新分配人力资源时，那么项目不只会愈加推延，而且最后很能够会交付一个愈加软弱、更复杂的产品。
3. 扎温斯基定律（Zawinski's Law）“每个顺序都试图扩展，直到它包含了一个web效劳器。那些不能扩展的项目会被可以扩展的项目所取代。”
任务完成的时间会影响任务的量"
在这里，主要的项目管理阅历是，假设你不为概念性的里程碑设定大约的最前期限，那么项目将永远不会完成。这也阐明了在固定的时间线上迭代最小可行产品的重要性。
当然，我们也可以依据数据、处置才能、RAM等等来调整这条规律:
在运用完一切可用的存储空间/带宽/周期/RAM之前，数据/CPU/内存的运用会不断扩展
实践上，32GB对任何人来说都足够了，对吧?
5. 帕累托谬论（Pareto's Fallacy）帕累托准绳很容易被曲解，尤其是被管理层曲解。这通常会招致帕累托谬论:
“当你完成了80%时，你会以为你只剩下20%了。”
这里疏忽的关键部分是，这20%，其实需求你投入80%的时间。
一切部分的90%都是无用的。
是的，你的产品也包含在内。
7. 彼得准绳（The Peter Principle）在等级制度中，每个员工都倾向于升到他们不能胜任的级别。因此，随着时间的推移，每个岗位都有能够被不称职的员工占据。”
任何你本人的代码，假设你有6个月或更长的时间没有查看，就似乎是别人写的一样。
实践上，6个月曾经相当悲观了。
不过，有一点需求留意，那就是“Yo mom推论”:
只要原作者才可以批判代码;任何其他的负面反应都会被驳回。
9. Greenspun编程的第10条规则（Greenspun's 10th Rule of Programming）任何自定义开发的身份验证系统都包含一个特别的、非正式指定的、充溢错误的、缓慢的Kerberos完成。
这可以概括为普遍的NIH规则:“任何定制开发的系统都包含一个暂时的、非正式指定的、有bug的、缓慢的执行，而这些执行的对象有一半都是你拒绝运用的工业界标准。”
10. 冰山谬论（The Iceberg Fallacy）新软件产品的开发成本仅占一切权管理的总成本和预算的25%。
关于运维来说，有一句格言是这么说的：
“假设软件维护占总拥有成本的75%，那么运营支持就是剩下的75%。
【编辑引荐】
拳打育碧脚踢佳能，敲诈软件怎样就这么强
从美国继续网络训练环境（PCTE），看国际网络靶场技术实际
是时分展现真正的技术了！看看5G+物联网=？
美国国度安全局发布零信任安全模型指南 - 网络·安全技术周刊第477期
亚信安全与京东科技集团达成战略协作 携手推进网安技术创新
(责任编辑：admin)