发帖  主题  评论  推荐  标签 用户 查搜   用户 密码 自动 注册  
 
面向对象 设计模式 领域驱动设计 云架构 框架 开发教程 SOA 大数据 扩展性 并发编程 EDA 分布式 函数编程

15条软件开发的基本规律

  下面是15条来自软件开发实践中的基本规律法则:

奥卡姆剃刀

  这个著名的格言可以追溯到14世纪的哲学家和修士William_of_Ockham,奥卡姆剃刀(Occam's razor)通常描述为:

  在有多个相互竞争性的理论中,选择那个最少的假设解释的理论(因为假设越多,错误的概率越多)。

  这个原理最早至少能追溯到亚里士多德的“自然界选择最短的道路”。在大多数情况下,如果我们可以选择理论,那么无疑选择越简单的越好。

  但是这个原理被人们还总结简单有效原理:如无必要,勿增实体。切勿浪费较多东西去做,用较少的东西,同样可以做好的事情。也就是将复杂事情简单化。

  这种解释其实偏离了奥卡姆剃刀的原话,奥卡姆剃刀的原话中有一个前提是,存在多个相互竞争性理论的情况下,倾向于选择简单那一个。这句话的意思不等同于“如无必要,勿增实体”,因为后者的假设前提是“如无必要”,这个前提与奥卡姆剃刀原话的前提不是同一的,因为是否必要是非常主观的,假设当前只有一个方案,那么主观者会认为没有必要再探索其他方案了;如果过了一段时间,其他人又提出一个简单方案,这个主观者会认为已经没有必要再考虑第二个方案,尽管按照奥卡姆剃刀原意还是需要将这两个方案进行比较,有可能第二个方案更简单,能够入选。

  在多个方案中选择简单的,不代表否定进行多个方案的论证,如同我们进行软件开发与设计,如果仅仅认为功能足够可以运行了,没有必要再加入过多设计,设计模式和其他最佳实践是多余的,这种懒惰认识反而是有害的,相反,设计模式和最佳实践或者面向对象或者函数式方案有可能是出其意外地简单巧妙。这些如果你不首先进行复杂化,又如何能够在复杂基础上真正获得简单的解决方案呢?

 

Hanlon的剃刀(Hanlon's razor

  Never attribute to malice what can be adequately explained by stupidity,如果能够使用无知解释,就无需归因于恶意。

  软件测试中经常让程序员懊恼的是测试员或用户总是挑选自己的死穴进行测试,其实大部分情况下他们不是恶意或故意的,而是对你的程序逻辑的无知导致,这种无知的测试正是软件测试的无盲点测试。

  现实生活中也是经常有这样情况,很多人出于无知,或者无意识地犯错,那么我们就不能再归因于他们出于恶意,因为恶意必须是意识到了再去故意违反,所以,在法律上,故意杀人与正当防卫的无意杀人在量刑上是区别对待的。

  Hanlon的剃刀也是让我们宽宏原谅别人的一个约定俗成的理由。

 

帕累托原则(二八定律 80/20定律)

  “80%的影响源于20%的原因。”1897年,意大利经济学者帕累托发现:20%的人占有80%的社会财富。

  在软件开发调试中,我们会发现大量问题和Bug,也许你会感到泄气,但是奇怪的是,当你解决一个问题后,会发现其他很多错误竟然消失了,这说明,大部分的问题其实都是由一些共同原因引起的。

  简而言之,立刻解决许多问题的最快方法是找到共同的根源并修复他们。

 

达克效应(邓宁-克鲁格效应(Dunning-Kruger effect)

  "非熟练专业人员经常会对自己的能力产生认知偏差,以为自己的能力比他们实际能力要强大得多“

  这个定律认为相对不熟练的人会遭受虚幻的优越感,错误地评估他们的真实能力,用中国俗语解释:满瓶不动半瓶摇。当然一些研究表明,不同的社会文化也在其中发挥作用。例如,东方人往往会低估自己的能力,不断寻找机会提高自己和他人。

  类似概念有:儒家孔子认为”知之为知之不知为不知“,苏格拉底认为“真正的知识是知道自己的无知的程度“。老子:知人者智,自知者明。

 

林纳斯定律

  雷蒙德的名言,“足够多的眼睛,就可让所有问题浮现。”(Given enough eyeballs, all bugs are shallow)

  换句话说,如果你不能找到问题,就去寻求他人的帮助。 这也是为什么需要结对编程和软件测试的原因。

 

健壮性原则(又名Postel法则/伯斯塔尔法则)

  在软件开发中有一个基本思想,特别是API设计等领域,可以简明地表达为健壮性:

  严以律己,宽以待人。

  最早这个规范是针对TCP协议设计的,当代码发送命令或数据到其他机器时应该完全符合规格,但代码接收其他输入应该可以接受非标准一致的输入,只要这个输入意思清楚。

   在函数式编程中,这个原理表现为输入类型是逆变的(contravariant),而输出类型应该是协变的(covariant)。在程序员中,产生兼容的功能,原理是推广[引文需要]的形式在输出型的输入类型和协变是逆变。

 

Eagleson定律

   程序员离开项目一段时间后再去看看自己的代码,心里经常可能骂娘,这是哪个白痴写的代码?

  自己的代码如果六个月以上没有没有再看,如同其他人编写一样。

   记住,下次你再加入一个项目你已经离开好几个月。 代码是 不再你的代码 ;它是别人的,你现在负责改善。

 

彼得原理

   彼得原理是管理心理学的一种心理学效应,指每个员工不断迁升,最终趋向于上升到他所不能胜任的岗位。对一个组织而言,一旦组织中的相当部分人员被推到了其不称职的职位,就会造成组织的人浮于事,效率低下,导致平庸者出人头地,发展停滞。

 

呆伯特的原则

  漫画的主人公呆伯特,是一位白领工人、电气工程师,也是全世界闻名的倒霉蛋,其上司愚蠢、官僚。其原则是:

  没有能力的员工将比有能力的员工更能提拔到管理岗位,从而将他们从实际工作中去除,以减少他们可能造成的危害。

 

霍夫斯塔特定律

  实际花费的时间总是超过你的预期,所以,你只能加班,唉,程序员加班很苦逼啊。

 

90-90 规则

  因为事情总是出错,因为人是出了名的不擅长估算自己的技术水平:

  "百分之90开发时间花在90%代码上,剩余的10%代码量却又花费了90%的开发时间“

  这也许解释了为什么那么多软件项目最后超出预算

 

帕金森定律

  是官僚主义或官僚主义现象的一种别称,被称为二十世纪西方文化三大发现之一,“官场病”、“组织麻痹病”或者“大企业病”:

  工作量总是会填满其所需的时间。

  总是有做不完的工作,

 

塞尔定律(Sayre's Law)

  争议的强度总是和价值成反比。也就是说:重要性越少的事情,人们越有热情去争议。

 

帕金森琐碎定律

  管理学上,帕金森发现一种称为琐碎定律现象。在讨论非常专业而且金额庞大的事情时,一般人由于缺乏专业知识,不敢随便发言,以免失言,贻笑大方,因此多半都会肯定(或逃避)该重大方案,而提些与主题无关的鸡毛蒜皮小事。相对的,对于简单的琐碎小事,由于平常大家都会接触到而且有相当的认识,反而意见特别多,帕金森称此现象为琐碎定律。

  在任何议程项目上所花费的时间与金钱之和成反比。

 

好辩定律

  人们越理解某事物,他们就越愿意去争论,他们也越好这口。

 

敏捷项目

 

解道移动版 | 关注解道 | 联系解道 | 关于解道 | 广告联系 | 网站地图 | 设为首页

沪ICP证12033263 如有意见请与我们联系 Powered by JdonFramework
返回顶部