现在的互联网公司，基本上有点规模的公司都会有公共平台组（部），主要负责开发一些公共框架，基础库代码等。比如前端开发要搞一个framework，后端也有日志处理，权限管理，登录管理， rpc调用框架等。这些东西因为每一个业务开发部门都会用到，所以专门会有开发人员来维护这些公共代码。 康威定律告诉我们任何设计系统的组织，必然会产生以下设计结果：即其结构就是该组织沟通结构的写照。简单来说： 产品必然是其组织沟通结构的缩影（Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.).所以在公共平台组（部）和业务开发组之间，业务逻辑和公共逻辑之间，就会产生一些很有意思的问题，这需要我们好好的思考思考。
首先，我们为什么要有公共平台组或者公共代码？公共代码其中最重要的作用是为业务开发提供方便，让业务开发组更快的完成工作，更快的完成工作才能使得公司更快的适应变化，让公司在激烈的市场竞争中战胜对手，完成公司的进化升级。就好比这几年流行的装配式建筑，建筑公司不再是一砖一瓦的盖楼，而是从工地直接采购预制墙，搬到建筑工地，吊机直接拼装。 效率大大提升。建筑工地就好比业务开发组，在北京，上海，全球各地都可以快速盖楼。预制墙工地就好比公共代码，可以一处造墙，处处使用。
上面提到公共代码的好处，实际上公共代码也会带来一些坏处。让然类比于建筑行业。如果某一处施工工地对建筑有比较苛刻的要求。预制墙不能直接拿来使用，这种情况下，我们怎么才能满足建筑工地（业务开发）的需求呢？
- 第一种方案，由建筑工地提出需求，让预制墙工地重新设计满足需求的预制墙。但是这种情况下，预制墙工地仔细一核算，要改造现有设备，成本太高。就不愿因针对这种情况特殊满足工地需要。
- 第二种方案，建筑工地自己买砖自己造墙。这又势必造成建筑工地的成本相较于买墙过高。
- 第三种方案，由建筑工地改造预制墙，把一块大的预制墙用切割机切成两半，或者采用砖和预制墙混合建造。这种又会适配和安全的问题，预制墙和砖是否可以一块用，砖的长宽高和预制墙是否能匹配？ 混合建造的墙是否满足安全标准？这些都是建筑师需要考虑的。
建筑行业的规律也同样适用于软件开发行业。framework层面的公共代码能不能最大化满足业务开发的需求，而且要做到既快又好。还要提供足够的灵活性给业务开发，让他们用的顺手。根据笔者的经验看，能够做到这几点的framework真是寥寥无几。要不只提供灵活性，要不只提供便利性。实际上，真的是鱼和熊掌不可兼得吗？实际上我们是可以鱼和熊掌兼得的。 就好比如很多语言的标准库都是提供两个层面的接口的， 一个是底层接口，提供更低层次接近于操作系统的接口的API，一个是高层接口，提供经过封装的，屏蔽操作系统底层接口的应用开发层的API。这两种层次的API就可以满足应用开发的各种需求了。
很多时候，作为业务开发，经常挂在嘴上的就是做不了，底层不支持。让后通知底层（公共平台组）提供接口支持。公共平台组有觉得这个需求很刁钻，不希望提供支持。最终就是相互推诿，两败俱伤。产品经理提出来的需求业务开发不能满足，业务开发推脱给公共平台组， 公共平台组认为这个不是公共的东西，应该有业务开发来负责，业务开发又觉得公共平台没有提供相关的底层接口，没法改。最后导致产品经理觉得很委屈。感觉公司养了一帮无能之辈。实际上，如果有良好设计的接口，这些问题是可以避免的。
所以我就在思考，当我们提供公共产品的时候，怎么样才能能好的满足不同层次的需求？ 什么样的粒度才是合适的？当然，这个很难一概而论，只能具体问题具体分析了。在此不再讨论了。
上面讲的都是接口API设计的问题，下面再讲一个公共平台组合业务开发组的关系的问题。 这个每个公司都不一样，各有各的实践，但是大都是一下几种。
1. 公共平台组比较强势，推动着整个公司技术的发展。
2. 业务开发比较强势，提出的需求公共平台组都要提供必要的支持。
那种是对的？ 我觉得都不对，公共平台组合业务开发组之间的关系应该是平等的，没有谁应该听谁的。如果公共平台组比较强势，而且提供的接口API又没有灵活性的话，势必让业务开发感觉很累，业务开发强势的话，公共平台肯定会很累。我觉得公共平台提供的东西应该是服务于业务开发的， 应该是卖方，业务开发是买方。业务开发如果觉得公共平台提供的东西不够好，大可以不买。公共平台如果觉得自己的东西挺不错，当然也应该大声吆喝着卖。