Brooks法则

07-图的着色 注：所写主要参考为许胤龙《图论导引》，因觉得此书所写不合理，故附参考张先迪《图论及其应用》 顶点着色 k-顶点着色：把kkk个颜色分配给图GGG的顶点，每个顶点分配一种颜色，称为k-顶点着色 正常k-顶点着色：若相邻顶点颜色不同，则为正常k-顶点着色，此时称GGG为可k-顶点着色的。 顶点色数：使图G可正常顶点着色的最少颜色数k，为图G的顶点色数，简称色数，记为X(G)X(G)X(G) 正常k-顶点着色是顶点集合的一个划分。 X(G)=2X(G) = 2X(G)=2 当且仅当它是有边二.

hi，我是熵减，见字如面。 在软件项目开发中，你是否遇到过这种情况： 你的项目进度落后了，你的老板或客户不满意，你的团队压力很大，你觉得需要增加一些人手来加快速度。但是，当你增加了新的成员后，你发现项目的进度并没有提高，反而变得更慢了，而且出现了更多的问题和冲突。 这就是布鲁克定律(Brook’s Law)的一个典型例子。 什么是布鲁克定律(Brook’s Law)？ 布鲁克定律(Brook...

布鲁克斯法则(Brook's Law)简单理解就是：向进度落后的IT项目增加人手，只会使项目更加落后。从项目管理PMP角度来说，新成员加入将使团队重新开始，增加磨合期，从而导致项目进度更加落后。

布鲁克斯定律： 人月=人*月，月≠人月/人 极端情况下，Brooks定律会出现这样的情况：“投入更多的人到一项延迟的工作上，可以导致该项工作更加延迟”。 Barry Bohem：可以将软件开发进度压缩25%，但是不能再多了 200/20/6X现象： –人数增加1倍，工期缩短20%，缺陷增加6倍 反思： –1 在实践中，我们是否经常通过给项目组增加人手的方式加快进度？ –2 有哪些合理的加快进度的措施？ 定律分析 布鲁克斯定律（Brooks’Law）里面用了几个字眼“人、月”。是的，此布鲁克斯就.

其中，( C ) 是沟通渠道的数量，( N ) 是团队人数。这种情况下，增加人手并不会加快开发，反而会带来更多问题。在这个过程中，老成员需要花时间指导新成员，导致。这与直觉相悖，但在现实软件开发中屡试不爽。团队成员越多，沟通成本呈指数增长。，只有科学管理团队，才能真正提高开发效率！那么不同团队可以并行开发，减少沟通成本。有些任务本质上不能被无限拆分。，最终会导致项目效率下降。，反而降低了整体生产力。

<br />布鲁克斯法则，据说是经典的管理定律之一。<br /> <br />布鲁克斯法则，据说是北卡罗来纳大学计算机科学教授Frederick P. Brooks，Jr.提出的经典理论！<br /> <br />为什么用个“据说”，因为这都是别人和我说的，所以我加上了这两个字！<br /> <br />“为推迟的软件增加人力将使得软件时间发布更晚。 这是因为后来者需要加快速度，同时还要与前任进行沟通，从而使得开发团队增加了更多的开发时间，这个时间超过了新增程序员所做的贡献。从理论上说，软件发展陷入僵局是可

A：“离系统上线只有3个月时间了，还有这么多功能没有做，怎么办？” B：“可以从隔壁团队抽调一个工程师来帮忙吗？领导对这个项目很重视。” A：“好，应该可以抽调两个来，他们都是经验丰富的程序员，争取在1个月内完成。” 最后他们成功地把项目拖延了4个月，比没有添加人手的预计还要晚。 向进度落后的项目中增加人手只会使进度更加落后。 ——《人月神话》里面提到的Brook

布鲁克斯是上世纪60年代IBM System/360的操作系统OS/360的开发负责人，这之后基于当时的经验写了人月神話一书。 这是描述大规模软件开发难度的一本划时代的书。如果是IT从业人员是必读的一本书。软件开发人员或是项目管理者的话，听我一句话，读一读比较好。我的日记里也介绍了好几次。 先不谈人月神话的第二章，看下面的示例。有这样一个项目需要12个人月，这样3个人4个月就能完成该任务。然后，每个月设定观测点A/B/C/D。

虽然面试套路众多，但对于技术面试来说，主要还是考察一个人的技术能力和沟通能力。不同类型的面试官根据自身的理解问的问题也不尽相同，没有规律可循。上面提到的关于这些JAVA基础、三大框架、项目经验、并发编程、JVM及调优、网络、设计模式、spring+mybatis源码解读、Mysql调优、分布式监控、消息队列、分布式存储等等面试题笔记及资料。

最主要的观点在第二章人月神话。 就是Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。 Adding manpower to a late software project makes it later. 一、缺乏进度安排是造成项目滞后最主要的原因，容易出现问题的点： 错误的估计了项目进度。没有预估可能的风险，假设一切顺利的情况下，过于乐观的估计了项目进度。  错误

一、墨菲定律（Murphy’s Law） 二、布鲁克定律（Brook’s Law） 三、霍夫施塔特定律（Hofstadter’s Law） 四、康威定律（Conway’s Law） 五、波斯托定律（Postel’s Law） 六、帕累托法则（Pareto Principle） 七、彼得法则（The Peter Principle） 八、基尔霍夫法则（Kerchkhoff’s Principle） 九、莱纳斯定律（Linus’s Law） 十、摩尔定律（Moore’s Law）

《图论与网络优化》学习笔记（第6-8章） 上课时间：2023年10月——2024年1月 上课地点：国防科技大学 授课老师：戴丽 教材：戴丽.《图论与网络优化》 注：部分笔记根据自己的理解进行改动，可能不是很严谨，但便于理解。 第六章 独立集及其算法 6.1 独立集和覆盖 独立集：设 S⊆V(G)S\subseteq V(G)S⊆V(G) ，若 SSS 中任意两个顶点在 GGG 中都不相邻，则称顶点子集 SSS 是 GGG 的一个顶点独立集，简称独立集。含有 kkk 个顶点的独立集称为 kkk独立集。 团

康威定律——微服务的理论基础 微服务# 系统架构 前言微服务现在大行其道，大家都在追，也都觉得很对，很多公司就算是用户量不大也都要上微服务，赶一波潮流但是似乎没有很充足的理论基础说明这是正确的，给人的感觉是 不明觉厉 。前段时间看了 Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》（是 Design RESTful API 的作者）一个分享，觉得很有帮助，结合自己的一些思考，整理了该演讲的内容。可能出乎很多人意料之外的一个事实是，微服务很多核心理念其...

布鲁克斯法则 (Brooks’s Law) 软件开发后期，添加人力只会使项目开发得更慢。 软件领域应用 这个定律表明，在许多情况下，试图通过增加人力来加速已延期项目的交付，将会使项目交付得更晚。布鲁克斯也明白，这是一种过度简化。但一般的论据是，新资源的时间增加和通信开销，会在短期内使开发速度减慢。而且，许多任务是密不可分的，换句话说，这样可以使更多的资源之间能轻易分配，这也意味着潜在的速度增长也更低。 观点 《神话人月》的布鲁克斯定律说：“为一个较晚的软件项目增加人力会使其变得更晚” 加入我们共同进

布鲁克斯定律说“为一个延误的IT项目增加人员，将导致更多的延误”，意思是任何软件的开发都有所谓的“关键路径”，因此任何一个软件的开发都需要一定的最少时间，靠增加人力投入不可能缩短这个最低时间。

总则：必先懂得原则，才懂得推翻原则。 KISS原则：keep it simple，keep it stupid. OO原则： – Abstraction（抽象） – Encapsulation（封装） – Modularity（模块化） – Hierarchy（分层） 设计模式基本原则： – 针对接口编程，而不要针对实现编程 – 达成高内聚合低耦合，提高复用 – 提倡优

英文原文：11 Laws of The System Thinking in Software Development 　　“我会更加努力地工作” —— 一匹名叫Boxer的马（出自乔治•奥威尔的《动物农庄》） 　　彼得•圣吉在其著作《第五项修炼》中提到的系统思维定律同样适用于软件开发。 　　 　　1. 今日的问题源于昨日的解决方案（Today’s problems come from yes

  布鲁克斯定律：      人月=人*月，月≠人月/人      极端情况下，Brooks定律会出现这样的情况：“投入更多的人到一项延迟的工作上，可以导致该项工作更加延迟”。 Barry Bohem：可以将软件开发进度压缩25%，但是不能再多了200/20/6X现象：–人数增加1倍，工期缩短20%，缺陷增加6倍   反思：–1 在实践中，我们是否经常通过给项目组增加人手的方式加快进度？...