认识达内从这里开始

对于程序员来说，在学习软件编程开发技术的过程中，除了需要掌握开发语言本身的技术能力以外，还需要掌握不同情况下的开发定律以及开发技巧才能更好的完成工作，下面我们就一起来了解一下具体内容吧。

一、墨菲定律(Murphy’sLaw)

可能是著名的定律之一，主要是因为它不仅适用于软件开发。

如果事情可能出错，它就会出错。

一个推论：那些有效的(代码)，你可能反而没有写出来。

二个推论：诅咒是一门所有程序员都能流利说出来的语言。

结论：电脑会按照你所写的(代码)去做，而不是按照你所想的去做。

防御性编程、版本控制、末日场景(针对那些该死的僵尸服务器攻击)、TDD、MDD，等等，这些都是针对这一定律的防御性实践。

二、布鲁克定律(Brook’sLaw)

大多数开发人员都有意无意地经历过布鲁克定律，该定律指出：

为已经延期的软件项目增加人手只会让项目延期得更厉害。

如果一个项目出现了延期，只是简单地增加人手很可能会带来灾难性的后果。对编程效率、软件开发方法、技术架构等因素进行评审总是会带来更好的结果。如果没有，那说明霍夫施塔特定律也在起作用。

三、霍夫施塔特定律(Hofstadter’sLaw)

霍夫施塔特定律由DouglasHofstadter提出，并以他的名字命名。

当然，不要将这个定律与电视剧《大爆炸》里的LeonardHofstadter混淆起来了，尽管他说的一些话对某些人来说是有一点意义的。

这个定律指出：

即使你考虑到了霍夫施塔特定律，项目的实际完成时间总是比预期的要长。

这个“定律”是关于准确预估完成复杂任务所需时间的难度。这个定律具有递归性，反映了预估复杂项目的难度，尽管你可能已经做出了大的努力，而且也知道任务的复杂性。

这就是为什么在进行项目预估时必须要有一个缓冲区。

四、康威定律(Conway’sLaw)

软件的结构反映了开发软件的组织的结构。

或者说得更清楚一点：

组织所设计的系统的结构受限于组织的通信结构。

很多组织是根据功能性技能来划分团队的，所以会有前端开发团队、后端开发团队和数据库开发团队。简单地说，如果某人想要改变的东西属于其他人，那么他就很难改变这些东西。

现在越来越多的组织根据有界上下文来组建团队，而微服务等架构也在根据服务边界而不是孤立的技术架构分区来组建团队。

因此，根据目标软件架构来组建团队可以更容易实现软件架构，而这就是对抗康威法律的一种有效方式。

五、波斯托定律(Postel’sLaw)或鲁棒性法则

保守输出，自由输入。

JonPostel初将它作为实现健壮的TCP的一个原则。这个原则也体现在HTML中，HTML的成败可以归因于它的很多属性，但究竟HTML是成功的还是失败的，不同的人有不同的看法。

六、帕累托法则(ParetoPrinciple)或80/20法则

对于很多现象，80%的后果源于20%的原因。

80%的bug来自20%的代码，这个说的就是帕累托法则。

还有人说，公司里80%的工作是由20%的员工完成的，问题是你并不清楚是哪20%员工。

七、彼得法则(ThePeterPrinciple)

这是一个相当令人沮丧的定律，特别是如果你碰巧亲身经历过。

在一个等级制度中，每个员工都倾向于晋升到他无法胜任的职位。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。