软件工程必看——10条你最容易忽视的经典法则

2021-03-04 20:22 338 阅读 ID:272
新智元
新智元


    本文列出了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%。”


    参考资料:

    https://www.netmeister.org/blog/software-engineering-laws.html

    免责声明:作者保留权利,不代表本站立场。如想了解更多和作者有关的信息可以查看页面右侧作者信息卡片。
    反馈
    to-top--btn