这是一个负载平衡的艺术 博客分类： 组织模式 游戏设计模式.net
程序员文章站
2024-02-21 12:08:10
...
最近在读James Coplien的组织模式。觉得最有意思的还是这张图。
最近公司级别组织了一次Open Discussion，总结来总结去，问题都是“沟通问题”，根源呢就是“价值观”。项目级别也做过好多次Retrospective，也是那句老话“沟通问题”。Cope总结得非常好，他说软件开发组织有多高效，主要就是取决于沟通的强度。上面那张图就很形象地标榜出了什么是高强度，健康的沟通。我觉得软件开发中只要解决两个问题：
1、从技术层面，怎么解决控制复杂度的问题。主要的手段就是Divide and Conquer和Compression。分模块分子系统就是Divide and Conquer，分函数分层就是Compression。
2、从团队，组织层面，怎么解决高效高强度的沟通问题。
但是这两个方向的问题，最终结果似乎是“殊途同归”的。控制复杂度似乎最重要的就是控制包的依赖数量和方向。做到均衡的负载，不能让太多的包都依赖于同一个包，导致所有的改动都要经过同个包。建模良好的系统不应该出现一堆人都在改同一个类的现象。除非这个包或者类处于更高更稳定的抽象级别，最极端的例子就是.NET Framework中的那些类。
而沟通问题也是在做均衡的负载。在上面的图我看到的是平衡的负载，没有人是Overloaded的。
在这张图里，我们就明显的可以发现有人是Overloaded的。在你的团队里有这样人吗？很多项目里的项目经理，不但要管项目，管需求还要管技术，显然是会Overloaded。有的项目专门有人负责“沟通”，就是他去和客户沟通，然后回来和程序员沟通，然后和QA沟通。很快，沟通就变成他的全职工作，那么他的附加值是什么呢？只要团队内有这样的Overloaded的角色，他们就会变成薄弱点。一旦团队的规模变大，外部的压力变大，就会整体垮掉。所以，平均负载是关键。
有一个非常形象的类比。就是Bridge游戏。这个游戏让你设计钢铁互相搭配的形状，设计一座桥梁，然后让汽车从上面通过。如果受压大的钢条就会变红，超过负载就会断掉。
最近公司级别组织了一次Open Discussion，总结来总结去，问题都是“沟通问题”，根源呢就是“价值观”。项目级别也做过好多次Retrospective，也是那句老话“沟通问题”。Cope总结得非常好，他说软件开发组织有多高效，主要就是取决于沟通的强度。上面那张图就很形象地标榜出了什么是高强度，健康的沟通。我觉得软件开发中只要解决两个问题：
1、从技术层面，怎么解决控制复杂度的问题。主要的手段就是Divide and Conquer和Compression。分模块分子系统就是Divide and Conquer，分函数分层就是Compression。
2、从团队，组织层面，怎么解决高效高强度的沟通问题。
但是这两个方向的问题，最终结果似乎是“殊途同归”的。控制复杂度似乎最重要的就是控制包的依赖数量和方向。做到均衡的负载，不能让太多的包都依赖于同一个包，导致所有的改动都要经过同个包。建模良好的系统不应该出现一堆人都在改同一个类的现象。除非这个包或者类处于更高更稳定的抽象级别，最极端的例子就是.NET Framework中的那些类。
而沟通问题也是在做均衡的负载。在上面的图我看到的是平衡的负载，没有人是Overloaded的。
在这张图里，我们就明显的可以发现有人是Overloaded的。在你的团队里有这样人吗？很多项目里的项目经理，不但要管项目，管需求还要管技术，显然是会Overloaded。有的项目专门有人负责“沟通”，就是他去和客户沟通，然后回来和程序员沟通，然后和QA沟通。很快，沟通就变成他的全职工作，那么他的附加值是什么呢？只要团队内有这样的Overloaded的角色，他们就会变成薄弱点。一旦团队的规模变大，外部的压力变大，就会整体垮掉。所以，平均负载是关键。
有一个非常形象的类比。就是Bridge游戏。这个游戏让你设计钢铁互相搭配的形状，设计一座桥梁，然后让汽车从上面通过。如果受压大的钢条就会变红，超过负载就会断掉。
