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

上传人:lao****ou 文档编号:214553 上传时间:2023-05-29 格式:DOCX 页数:6 大小:65.63KB
下载 相关 举报
99%的开发者认不全的软件开发定律你知道哪些.docx_第1页
第1页 / 共6页
99%的开发者认不全的软件开发定律你知道哪些.docx_第2页
第2页 / 共6页
99%的开发者认不全的软件开发定律你知道哪些.docx_第3页
第3页 / 共6页
99%的开发者认不全的软件开发定律你知道哪些.docx_第4页
第4页 / 共6页
99%的开发者认不全的软件开发定律你知道哪些.docx_第5页
第5页 / 共6页
亲,该文档总共6页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《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同步哦,欢迎各位 大爷赏光。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 应用文档 > 汇报材料

copyright@ 2008-2022 001doc.com网站版权所有   

经营许可证编号:宁ICP备2022001085号

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有,必要时第一文库网拥有上传用户文档的转载和下载权。第一文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知第一文库网,我们立即给予删除!



客服