分层架构与公司组织

　　最后，我们从问题展开再回到问题本身，到底应该以功能层面分拆还是以软件结构进行分拆，该同事给出的答案是No Bullet，在这里我想更展开说一下，我们回到分层的目的，其实无外乎三者： 分工、重用、可维护。而软件的架构本身是强调“高内聚，低耦合”。所以我们在划分该架构时也要遵循上面的原则，那么更加标准的答案应该是优先功能划分，然后结构划分。例如CRM与统计功能彼此独立，那么应该将二者分开，是否应该划分的逻辑很简单，这两者之间有什么需要共享的模块(Service)，有多少重复的方法。但是过度的结构划分会产生重用性变低的情况，我曾经见过每个功能划分一个MVC，例如Note, User，这会造成更大的混乱。

　　公司架构

　　最近一年极光推送的快速成长，已经从几十人的小公司发展为150余人的公司，所以我进来花了更多精力去思考公司的组织结构问题，希望能让公司更加高效的运转。

　　其实公司的组织与软件架构是同样的逻辑：

　　1 高内聚低耦合。无论我们承认还是不承认，跨部门沟通永远是一个公司最大的痛，所以作为组织架构的设计，最重要的就是如何使跨部门沟通变得最少，或者只有一个接口来做这件事情。从这一点来看，也许我们需要对组织架构做更多的思考。

　　2 关于业务逻辑分还是软件功能分。这一点其实对应的是我们到底是以事业部的方式组织，还是以职责部门的方式组织。在我看来依然是同样的逻辑，当项目足够多的时候，一定要优先以事业部的方式划分，原因很简单，提高整个部门的内聚性，每当任何一个问题产生时，总会有一个中间人(事业部GM)来站出来平衡利益关系，这个利益包含技术和产品的博弈，技术和测试的博弈，产品和运营的博弈等等。之前我给老板讲过这样一个逻辑，为什么一个CEO下面最多只能有四到五个高管，因为每当两个高管进行跨部门合作沟通时，就需要一个利益无关人平衡双方关系，如果是5个人，那么就是(5*4 / 2 = 10)种组合关系，而当这个数字增加到10时，组合关系就变成了45种，这还没有算上三个部门合作的组合关系。这也是我为何一直认为扁平化组织关系并不可行的原因。