午夜杂谈:浅论工程师技术的自由度?

曾经听一位前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提供给工程师可自由发挥的余地就太灵活了。在工程师个人效率最大的情况下，团队整体效率反而是最低的。

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