分块云计算

核心提示： 图5. UI也分块 这样一来，某个分块的开发者可以全方位地处理问题，分块云计算(6)，从UI一直到存储，不必与其它团队同步，对松散耦合的关注成了唯一的决定因素，以至于忘了搭配上它的好朋友——高内聚，对实际生产率的潜在影响是巨大的，巨型的团队经常有人向我们求助

图5. UI也分块

这样一来，某个分块的开发者可以全方位地处理问题，从UI一直到存储，不必与其它团队同步。对实际生产率的潜在影响是巨大的。

巨型的团队

经常有人向我们求助，抱怨说他们100人的大团队没办法达到期望的生产效率。

每一次，我都得到同样的结论。不要那样做！100名开发者在同一个团队里，太可怕了，失败风险太大了。即使你再加20个人！

虽然已经出版了30年，读过《人月神话》[Brooks MMM]的人还是少得出奇。真糟糕。（书名“人月神话”的意思是，向一个进度落后的项目增加更多开发者，只会让它更落后。书里还阐述了很多重要的思想。）

所以，就算退一步说你真的有一个规模庞大的问题要解决，你也真的需要100名开发者。请一定要小心谨慎地将大团队分成若干个小规模的、尽可能相互隔离的团队，以便每个团队能够全速运行。

但是当你把大团队分成比如说100个新团队的时候，显然不会因此就消灭了复杂性。例子里面分成10-20个团队比只有1个团队好，并不表示分成100个会更好。请注意平衡。

SOA与松散耦合

说到平衡，两年前我曾经很不理解SOA的一些说法，还写了博客帖子[Nilsson SOA-Qs]请教答案。

我不理解的其中一点是为什么要极端的细粒度。为什么不用“定界上下文（Bounded Context）” [Evans DDD]的思维来看待服务呢，为什么需要粒度细到只有一行代码的服务……

Jim Webber在一篇文章里[Webber Anemic Service Model]讨论过这个问题，我认为他说得很有道理。对松散耦合的关注成了唯一的决定因素，以至于忘了搭配上它的好朋友——高内聚，才导致出现令我困惑不解的奇怪说法。