曾经听一位前Leader(曾任ebay中间件团队负责人)讲过，国外的程序员相对更有geek精神，在技术选型上也更有自由度，比如开发语言之类的。当时听后甚是羡慕。可随着工作年限的增长，回过头想这件事情，至少在目前国内环境下是适用的吗?

因此大多时候，一种武器装备从研发到服役可能需要经过很长一段时间。其中不仅仅是武器本身的研发周期，还有与武器装备相关配套的建设等。只有装备、后勤、人员共同发力，才能充分发挥一种新式装备的最大威力。

以印度空军为反例。目前三哥空军汇集了全世界各式名牌战机，如美国F-16、苏-30系列、法国幻影2000等。可这哪是去打仗，整个一万国空博会。首先，这些来自不同国家的装备之间如何协同配合就是一个大问题。其次，各机型零部件没有统一标准，后勤如何保障？最后，飞行员培养成本太高。飞机和汽车不一样，会开夏利的可以直接去开奔驰，会开F-16的能直接去开苏-30? 这不找“摔”吗。抛开单个战机的格斗能力，综合作战实力别说与我国最新三代机、四代机PK，就拿早期山寨米格21(苏)系列的改良版歼-7、歼-8都不一定打的过。

回到本文讨论的主题。在一家互联网公司中，工程师技术选型的自由度该如何界定? 经常听到，“我对这项技术比较熟悉，我建议用XXX“，更有甚者，“最近出了一项新的技术，我们用XXX吧”。

本质上讲，上述两种做法都在追求“个人效率”的最优化，但忽略了整体效率的最优化。在公司初创阶段这并不是问题，因为此时组织架构较简单更偏重于"个人英雄"主义。而在组织架构复杂的大型互联网公司，更强调组织协同，组织间的协同效率大于一切。以开发语言选型为例，众所周知互联网领域常用的开发语言有Java、Go、C/C++、Python、PHP等，如果不同团队或组织可以任意选择开发语言而缺少集团层面的整体规划的话，那很容易遭遇如下问题:

假如有一个服务为了不同语言的应用接入，需要针对各类语言提供客户端。开发成本以及后续的维护成本等都会成为系统迭代效率的瓶颈。尤其是在微服务化大趋势的今天，系统拆分的越来越细，系统间的调用链路错综复杂。在各类语言混用的情况下服务治理该如何去做？如果没有成熟的服务治理，能力如何复用? 能力不能复用，怎么中台化?

中台的概念最早产生于军事领域。与中台组织模式相反的是集团军组织模式。集团军通常由若干个师编成的军一级组织，一般隶属于战区或方面军。集团军中包含较完整的兵种，比如步兵、装甲兵、炮兵、防空兵、工程兵、通信兵、电子对抗兵、航空兵等。

集团军这种组织模式存在着兵种建设不均衡的问题。通常不同集团军根据其所在的位置承担着不同的战略目的。比如:

北京军区:主要防御俄罗斯、蒙古方向。如果俄罗斯进攻中国其装甲部队可以直穿蒙古草原威胁中国心脏，因此北京集团军特点是侧重重装甲。

济南军区:山东位于中间位置，一个重要使命是可以随时支援其他军区。因此济南军区的特点的灵活机动，重点发展空军和伞兵。

不同军区都有自己的战略侧重点，往往厚此薄彼。拿空军来说，每个集团军都有自己的独立空军，只是有的强一点，有的弱一点。从某种程度上来说，存在一定的重复建设问题。假如全国有一个统一的“空军服务中心“，可以按需向各集团军提供轰炸机轰炸服务、歼击机格斗服务、运输机运输服务等，那就可以集中力量把一件事情做好，而不必分散在各集团军。

而这个“空军服务中心”就可以称为面向全军的空军中台。

阵地战早已成为过去，现代战争的趋势是小部队渗透、游击战、特种战。虽然是小部队，但其身后是强大的中台做支撑。这也是“大中台小前台”的思想。而在互联网领域，市场机遇瞬息万变，谁能以最快的速度小成本快速试错谁就能取得市场先机。

举一个Web开发框架选型的例子。曾经问过师兄一个问题，为什么公司(前东家)还在用Webx这样的有十几年历史的老古董框架而不用现在流行spring mvc? Webx虽然历史久远，但其核心思想是"约定胜于配置"。也就是说框架把基本的事情都规定好了，比如文件放在什么位置、代码基本逻辑该怎么写。如果不按照约定，应用根本启动不起来。留给工程师可自由发挥的空间较小，所以绝大多数的应用都是一样的，学会了一个其他的只需要了解一下业务逻辑即可快速上手，学习成本接近0。

举个例子说下这样做的好处，比如同学A休假了，同学B临时补位。赶巧这一天线上异常了，同学B在不了解应用的情况下，根据出问题的URL就可以很快定位到出问题的代码。

相反，spring mvc提供给工程师可自由发挥的余地就太灵活了。在工程师个人效率最大的情况下，团队整体效率反而是最低的。相比，Webx牺牲了工程师部分的个性，换来了整体效率的最优化。

读下来，好像本文的观点是“扼杀工程师的选择空间和创造力”。我觉得最终还是要在“个人效率最大化”和“团队效率最大化”之间做好trade off!