中台|啥都复用不了，还谈什么狗屁中台( 三 )

所以复用要根据自身团队发展情况，业务实际需要灵活把握，也要根据公司的发展阶段，逐步的实现复用，总体来说复用的优先级技术层面复用优先于业务层面复用，团队内的复用优先于团队间的复用，项目级复用优先于产品级复用。
二、如何更好的复用老板要求复用有没有错？没有错！员工说复用太难是不是实情？是实情！作为技术领导者，我们的职责就是解决团队的困难，实现老板的目标。具体如何更好的复用，老谭根据自己的工作经验和对该问题的深度思考，提供一定的思路仅供参考。
1. 不要忽视技术栈的管理站在复用的角度，不同的开发语言之间是很难复用的，虽然对于互联网或者自运营的信息化而言，还可以通过服务共享的方式实现复用，而对于我们更多以本地化交付的软件产品研发而言，技术体系不统一对于复用和协同兼职就是噩梦。
老谭在负责公司研发之前，整个公司没有统一的技术栈，每个部门几乎都有自己的技术栈，当时存在.net，java，php等多种语言开发的系统，主流的Java语言还存在Jfinal、springboot、dubbo等不同的框架。
对于技术团队最容易的代码程序级别的复用因为技术体系的不统一而导致无法复用，团队资源无法流动平衡的问题，这对于我们中小规模的研发团队来说就是灾难。分散的组织必然带来不统一的技术架构，这就是有名的康威定律（后面还会详细介绍）。
结合我自己的工作经历，对于技术栈的管理提供以下思路供参考。
确定团队主流语言，主流开发框架，主流数据库等；
我们确定了Java语言为主流语言；springboot为主要开发框架；采用SpringCloud的微服务架构体系，；数据库第一选择为MySQL，新项目全部统一到MySQL。
减少非主流技术体系的资源投入，新的业务逐步以主流技术进行；
老谭之前团队使用比较小众的JFinal，同样向主流框架springboot切换；减少Dubbo的使用范围；严格控制非Java体系的资源投入，新业务可以采用Java开发的混合体系。
逐步向前后端分离的开发方式转变，大后端体系之后实行大前端；
我们做技术的都清楚，后端稳定，前端变化多端，前端的复用的优先级是远弱于后端的，但是对老板们可就不一样，后面的数据库，服务接口啥的他们也看不见，最直观的就是前端，所以不能忽视。我们最先确定下前端的开发框架VUE，防止前端技术的分化，传统的前端开发根据实际需要有准备实现架构的转变。其实这个转变在前期是需要增加投入的，毕竟两套体系前期要并行，老板质问为何要切换前后端分离，当然她不知道的是，如果我们不转变，我们现在连人（前后通吃）都招不到。
中间件不能滥用，新技术引进需要走技术评审。
技术人员都比较热衷各种中间件的使用，对新技术趋之若鹜，追求新技术没有错，创新也需要鼓励。但这些都需要管理，因为作为技术领导人，我们必须站在团队整体角度平衡成本、效率、效益的关系，所以通过技术评审，我们既能引进新技术，又能管理技术引进带来的学习成本，大面积推广的时机和条件。
通过这一系列的措施，我们至少在技术底层取得了适度的统一，不同团队之间的技术交流就消除了障碍，大家就容易共同积累，促进共享。
2. 统一架构，构建平台级应用技术栈的统一，只能让我们做到LV1和LV2层级的复用能力，再往上走就涉及到功能层面和业务层面了，而这更接近老板的视角了。所以实现更高层次的复用是每个技术领导人的追求，也是发挥自身专业能力的舞台。
但在这个环节我们往往会出现大问题，就是不能根据实际情况因地制宜，架构体系的弹性很大，没有严格的标准，只有根据实际情况的平衡，平衡是考验技术领导人的架构艺术，不要小瞧了这个能力。很多大厂的牛人去小企业做架构，太多失败的案例，不是架构不好，是没有用对地方。