曾經聽一位前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!