99%的开发者认不全的软件开发定律你知道哪些.docx

《99%的开发者认不全的软件开发定律你知道哪些.docx》由会员分享，可在线阅读，更多相关《99%的开发者认不全的软件开发定律你知道哪些.docx（6页珍藏版）》请在第一文库网上搜索。

1、99%的开发者认不全的软件开发定律，你知道哪些?这些著名的软件开发定律，你都知道哪些？与其他领域一样，软件开发领域也有一些非常有趣的定律。程序员、技术经 理和架构师们经常在会议和聊天中提到它们。作为小白，我们常常只有点头附和 的份，因为我们不希望让对方知道我们实际上根本不知道布鲁克、摩尔或者维斯 都是什么人。这些定律包括了一些法则或软件开发大神的名言。它们都很有趣，值得我们 一探究竟，而且每个定律背后都有令人惊叹的背景故事。在这篇文章中，与大家分享软件开发领域最著名和最常见的定律的解释和想 法。墨菲定律(Murphy, s Law)可能是最著名的定律之一，主要是因为它不仅适用于软件开发。如果事

2、情可能出错，它就会出错。第一个推论：那些有效的(代码)，你可能反而没有写出来。第二个推论：诅咒是唯一一门所有程序员都能流利说出来的语言。结论：电脑会按照你所写的(代码)去做，而不是按照你所想的去做。防御性编程、版本控制、末日场景(针对那些该死的僵尸服务器攻击)、TDD、 MDD,等等，这些都是针对这一定律的防御性实践。布鲁克定律(Brook, s Law)大多数开发人员都有意无意地经历过布鲁克定律，该定律指出：为已经延期的软件项目增加人手只会让项目延期得更厉害。如果一个项目出现了延期，只是简单地增加人手很可能会带来灾难性的后果。 对编程效率、软件开发方法、技术架构等因素进行评审总是会带来更好的

3、结果。 如果没有，那说明霍夫施塔特定律也在起作用。霍夫施塔特定律(HofStadters Law)霍夫施塔特定律由Douglas Hofstadter提出，并以他的名字命名。当然，不要将这个定律与电视剧大爆炸里的Leonard Hofstadter混淆起来了，尽管他说的一些话对某些人来说是有一点意义的。LEONARD HOFSTADTERTwelve years after high school and m still at the nerd table.这个定律指出：即使你考虑到了霍夫施塔特定律，项目的实际完成时间总是比预期的要长。这个“定律”是关于准确预估完成复杂任务所需时间的难度。这个

4、定律具有 递归性，反映了预估复杂项目的难度，尽管你可能已经做出了最大的努力，而且 也知道任务的复杂性。这就是为什么在进行项目预估时必须要有一个缓冲区。康威定律(Conway, S Law)软件的结构反映了开发软件的组织的结构。或者说得更清楚一点：组织所设计的系统的结构受限于组织的通信结构。很多组织是根据功能性技能来划分团队的，所以会有前端开发团队、后端开 发团队和数据库开发团队。简单地说，如果某人想要改变的东西属于其他人，那 么他就很难改变这些东西。现在越来越多的组织根据有界上下文来组建团队，而微服务等架构也在根据 服务边界而不是孤立的技术架构分区来组建团队。因此，根据目标软件架构来组建团队可

5、以更容易实现软件架构，而这就是对 抗康威法律的一种有效方式。波斯托定律(Postels Law)或鲁棒性法则保守输出，自由输入。Jon Postel最初将它作为实现健壮的TCP的一个原则。这个原则也体现在HTML中，HTML的成败可以归因于它的很多属性，但究竟HTML是成功的还是失 败的，不同的人有不同的看法。帕累托法则(Pareto Principle)或80/20法则对于很多现象，80%的后果源于20%的原因。80%的bug来自20%的代码，这个说的就是帕累托法则。还有人说，公司里80%的工作是由20%的员工完成的，问题是你并不清楚 是哪20%员工。彼得法则(The Peter Princ

6、iple)这是一个相当令人沮丧的定律，特别是如果你碰巧亲身经历过。在一个等级制度中，每个员工都倾向于晋升到他无法胜任的职位。呆伯特(DiIbert)系列漫画中有一些这方面的例子。.NO MANAGEMENT support, ambiguous GOALS, NO BUDGET, AND AN ANGRY TEAM OF OVERWORKED PEOPLE WHO UANT IT TO DIE?基尔霍夫法则(KerchkhofFs Principle)在密码学中，系统应该是安全的，即使系统的所有东西都是公开的一一除了 一小部分信息一一秘钥。这是公钥密码学的主要法则。莱纳斯定律(Linus, s

7、 Law)这是以LinUX之父LinUS Torvalds的名字命名的，该定律指出：如果有足够多的眼睛，所有的bug都将无所遁形。可以使用著名的大教堂与集市来描述这个定律，它解释了两种不同的自 由软件开发模型之间的对比：大教堂模型一一每个软件发行版都提供源代码，但发行版之间的代码开发仅限于一组专有的软件开发人员。集市模型一一代码开发通过互联网公开进行。结论？对源代码进行更广泛的公开测试、评审和实验，就会更快地发现各种 形式的bug0摩尔定律(Moore, s Law)单位成本的计算机算力每24个月翻一番。最流行的版本是说：集成电路上的晶体管数量大约每18个月会增加一倍。或者：计算机的处理速度每

8、两年翻一番！IN %l GORDON HOOR匕 Co-Founder of INT PREWCTtD COMPUTER PROCESINGRMR WOUlD DOUBxHERY TWO YtAK.Mee thCoNSIANT C.OREy LA(T HAC Ul IN PRACTICAL TeRNs MooRE FpT TO SUBTRACTTHtC0NTANT C, WHlCH cow PROC匕空(NG SPEtP.Proceft 亍厂 cPower . Pos /-jIn FUtMe - ThK J“NgCCT，4 小”沃斯定律(Wirth, s Law)软件比硬件更容易变慢。参考一下

9、摩尔定律吧！九九法则(Ninety-Ninety Rule)前90%的代码占用了 10%的时间，其余的10%代码占用了剩下的90%时 间。有人不同意这个的吗？克努特优化法则(Knuths Optimization Principle)过早优化是万恶之源。OPlMIZN6乐询砒5布WIba)IulNG& right?WRREPREnfflUREIY0P1iMlZU6先写代码，然后找出瓶颈，最后才修复！诺维格定律(Norvig, s Law)任何超过50%渗透率的技术都不会再次翻倍(无论在多少个月内)o真香定律别更新了，我学不动了！真香。资料：windy最后打个广告：力软敏捷开发框架(www. Iearun. cn), OA、ERP、CRM等企 业管理系统开发神器，这些定律都不是事儿，支持微信、APP同步哦，欢迎各位 大爷赏光。