软件开发的著名定律

任何一种不良现象的存在，都在传递着一种信息，这种信息会导致不良现象的无限扩展，必须高度警觉那些看起来是偶然的，轻微的“过错”，如果对这种行为不闻不问，纠正不力，就会纵容更多的人去打烂更多的窗户玻璃

破窗定律

凡事可能出错的事就一定会出错

墨菲定律（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。敏捷开发中将迭代引入，做到持续交付，快速验证，迅速反馈，持续改进。

第二定律：时间再多一件事情也不可能做的完美，但总有时间做完一件事情

想要架构成为什么样，就将团队分成怎样的结构。比如前后端分离的团队，架构就是基于前后端分离。在基于微服务设计的团队里，一个很好的理念是自管理。团队内部对于自己所负责的模块高度负责，进行端对端的开发以及运维。

第三定律：线型系统和线型组织架构间有潜在的异质同态特性

合久必分，分久必合，团队以及架构都是在不断优化的。一个团队随着人员的增加，沟通以及管理成本一定会增加。

第四定律：大的系统组织总是比小系统更倾向于分解

四个核心观点