软件开发的定律大部分的人都不认识你呢

与软件开发的其他领域一样,有一些非常有趣的法律.程序员,技术总监和架构师经常在聊天会话和中中提及它们.像小白一样,通常只会眨眼,因为我们不想离开另一部分知道我们不知道谁是布鲁克,摩尔或维斯.

这些法律包括一些软件开发的法律或神.它们非常有趣,值得我们探索,每个法律背后都有令人惊讶的背景故事.

在这篇文章中中,我将分享我对软件开发中最着名和最常见的法律的解释和想法.

墨菲定律

可能是最着名的法律之一,主要是因为它不仅适用于软件开发.

如果出现问题,就会出错.

有效的(代码)的第一个推断:,不能写它.

第二个推断:诅咒是所有程序员都可以流利地说的唯一语言.

结论:计算机将执行它所写的(代码)而不是它想要的东西.

防御性编程,版本控制,世界末日场景(对于那些该死的僵尸服务器攻击),TDD,MDD等.这些是这项法律的防御性做法.

法律布鲁克(布鲁克定律)

大多数开发人员故意经历过或不符合法则布鲁克,即

将员工添加到已推迟的软件项目中只会进一步延迟项目.

如果一个元素被推迟,简单地添加更多人可能会产生灾难性的后果.审查编程效率,软件开发方法,技术架构等因素将始终带来更好的结果.如果没有,那么请记住,霍夫施塔特的定律也有效.

法律霍夫施塔特(霍夫施塔特定律)

霍夫施塔特的法则由Douglas Hofstadter提出并以他的名字命名.

当然,不要在电视连续剧《大爆炸》中将此法与Leonard Hofstadter混淆,尽管他说的一些事情对某些人来说有些重要.

该法律规定了

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

这种"法律"指的是难以准确估计完成复杂任务所需的时间.这个定律是递归的,反映了估算复杂项目的难度,尽管你可能已经做得最好并且知道任务.复杂性.

这就是为什么在进行项目估算时应该有一个缓冲区的原因.

法律康威(康威定律)

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

或者使它更清晰

组织设计的系统结构受到组织通信结构的限制.

许多组织根据其功能划分团队,因此有前端开发团队,后端开发团队和数据库开发团队.简而言之,如果有人想要改变属于他人的东西,那么他很难改变.这些东西

沈阳软件公司

越来越多的组织正在基于有限的上下文创建团队,而诸如微服务之类的架构也在基于服务边界而不是孤立的技术架构分区创建团队.

因此,基于目标软件架构的团队的创建便于软件架构的实现,这是打击法律康威的有效方法.

波斯 Postel法则或稳健法

保守输出,免费进入.

它最初用作实现强大TCP的原则.这个原则也反映在HTML中中. HTML的成功或失败可归因于其许多属性,但如果HTML成功与否,不同的人会有不同的意见.

规则帕累托(帕累托原则)或80/20规则

对于许多现象,80%的后果来自20%的原因.

错误%来自20%的代码,即帕累托规则.

其他人说,公司80%的工作是由20%的员工完成的.问题在于,不知道20%的员工是谁.

彼得的原则

这是一个非常令人沮丧的法律,特别是如果你亲自体验它.

在中层次结构中,每个员工往往被提升到他们无法执行的职位.

保持伯特(Dilbert)漫画系列有一些例子.