软件开发的著名定律
2023-12-15 09:47:59 0 举报
AI智能生成
软件开发的著名定律
作者其他创作
大纲/内容
任何一种不良现象的存在,都在传递着一种信息,这种信息会导致不良现象的无限扩展,必须高度警觉那些看起来是偶然的,轻微的“过错”,如果对这种行为不闻不问,纠正不力,就会纵容更多的人去打烂更多的窗户玻璃
破窗定律
凡事可能出错的事就一定会出错
墨菲定律(Murphy's Law)
当一个措施本身成为目标时,它就不在是一个好的措施
古德哈特定律(Goodhart's Law)
事情总是要花费比你预想更长的时间
霍夫斯塔特(Hofstadter's Law)
向一个延期的项目增加人手只会让它延期得更加厉害
布鲁克斯法则(Brook's Law)
设计系统的组织其产生的设计等价于组织间的沟通结构。
反向理解:如果系统架构不支持,你无法建立一个高效的组织。
康威定律(Conway’s law)
软件开发的著名定律
对于复杂的,需要协作完成的系统开发,沟通是必须要持续提升的问题。每个团队由5-10人组成(沟通成本 = n(n-1)/2 - 《人月神话》),在团队内部进行频繁的、细粒度的沟通。对于团队外部,定义好接口,契约,只进行粗粒度的沟通。这样可以降低沟通成本,同时也符合高内聚,低耦合原则(代码和人员管理有些时候真是相通的)
第一定律:组织沟通方式会通过系统设计表达出来
我们在用kanban管理迭代时几乎都有一列是BAU(Business As Usual ),其中会包括一些日常修复的Bug Story。敏捷开发中将迭代引入,做到持续交付,快速验证,迅速反馈,持续改进。
第二定律:时间再多一件事情也不可能做的完美,但总有时间做完一件事情
想要架构成为什么样,就将团队分成怎样的结构。比如前后端分离的团队,架构就是基于前后端分离。在基于微服务设计的团队里,一个很好的理念是自管理。团队内部对于自己所负责的模块高度负责,进行端对端的开发以及运维。
第三定律:线型系统和线型组织架构间有潜在的异质同态特性
合久必分,分久必合,团队以及架构都是在不断优化的。一个团队随着人员的增加,沟通以及管理成本一定会增加。
第四定律:大的系统组织总是比小系统更倾向于分解
四个核心观点
0 条评论
回复 删除
下一页