曾經(jīng)聽一位前Leader(曾任ebay中間件團(tuán)隊負(fù)責(zé)人)講過，國外的程序員相對更有g(shù)eek精神，在技術(shù)選型上也更有自由度，比如開發(fā)語言之類的。當(dāng)時聽后甚是羨慕?？呻S著工作年限的增長，回過頭想這件事情，至少在目前國內(nèi)環(huán)境下是適用的嗎?

因此大多時候，一種武器裝備從研發(fā)到服役可能需要經(jīng)過很長一段時間。其中不僅僅是武器本身的研發(fā)周期，還有與武器裝備相關(guān)配套的建設(shè)等。只有裝備、后勤、人員共同發(fā)力，才能充分發(fā)揮一種新式裝備的最大威力。

以印度空軍為反例。目前三哥空軍匯集了全世界各式名牌戰(zhàn)機(jī)，如美國F-16、蘇-30系列、法國幻影2000等。可這哪是去打仗，整個一萬國空博會。首先，這些來自不同國家的裝備之間如何協(xié)同配合就是一個大問題。其次，各機(jī)型零部件沒有統(tǒng)一標(biāo)準(zhǔn)，后勤如何保障？最后，飛行員培養(yǎng)成本太高。飛機(jī)和汽車不一樣，會開夏利的可以直接去開奔馳，會開F-16的能直接去開蘇-30? 這不找“摔”嗎。拋開單個戰(zhàn)機(jī)的格斗能力，綜合作戰(zhàn)實力別說與我國最新三代機(jī)、四代機(jī)PK，就拿早期山寨米格21(蘇)系列的改良版殲-7、殲-8都不一定打的過。

回到本文討論的主題。在一家互聯(lián)網(wǎng)公司中，工程師技術(shù)選型的自由度該如何界定? 經(jīng)常聽到，“我對這項技術(shù)比較熟悉，我建議用XXX“，更有甚者，“最近出了一項新的技術(shù)，我們用XXX吧”。

本質(zhì)上講，上述兩種做法都在追求“個人效率”的最優(yōu)化，但忽略了整體效率的最優(yōu)化。在公司初創(chuàng)階段這并不是問題，因為此時組織架構(gòu)較簡單更偏重于"個人英雄"主義。而在組織架構(gòu)復(fù)雜的大型互聯(lián)網(wǎng)公司，更強調(diào)組織協(xié)同，組織間的協(xié)同效率大于一切。以開發(fā)語言選型為例，眾所周知互聯(lián)網(wǎng)領(lǐng)域常用的開發(fā)語言有Java、Go、C/C++、Python、PHP等，如果不同團(tuán)隊或組織可以任意選擇開發(fā)語言而缺少集團(tuán)層面的整體規(guī)劃的話，那很容易遭遇如下問題:

假如有一個服務(wù)為了不同語言的應(yīng)用接入，需要針對各類語言提供客戶端。開發(fā)成本以及后續(xù)的維護(hù)成本等都會成為系統(tǒng)迭代效率的瓶頸。尤其是在微服務(wù)化大趨勢的今天，系統(tǒng)拆分的越來越細(xì)，系統(tǒng)間的調(diào)用鏈路錯綜復(fù)雜。在各類語言混用的情況下服務(wù)治理該如何去做？如果沒有成熟的服務(wù)治理，能力如何復(fù)用? 能力不能復(fù)用，怎么中臺化?

中臺的概念最早產(chǎn)生于軍事領(lǐng)域。與中臺組織模式相反的是集團(tuán)軍組織模式。集團(tuán)軍通常由若干個師編成的軍一級組織，一般隸屬于戰(zhàn)區(qū)或方面軍。集團(tuán)軍中包含較完整的兵種，比如步兵、裝甲兵、炮兵、防空兵、工程兵、通信兵、電子對抗兵、航空兵等。

集團(tuán)軍這種組織模式存在著兵種建設(shè)不均衡的問題。通常不同集團(tuán)軍根據(jù)其所在的位置承擔(dān)著不同的戰(zhàn)略目的。比如:

北京軍區(qū):主要防御俄羅斯、蒙古方向。如果俄羅斯進(jìn)攻中國其裝甲部隊可以直穿蒙古草原威脅中國心臟，因此北京集團(tuán)軍特點是側(cè)重重裝甲。

濟(jì)南軍區(qū):山東位于中間位置，一個重要使命是可以隨時支援其他軍區(qū)。因此濟(jì)南軍區(qū)的特點的靈活機(jī)動，重點發(fā)展空軍和傘兵。

不同軍區(qū)都有自己的戰(zhàn)略側(cè)重點，往往厚此薄彼。拿空軍來說，每個集團(tuán)軍都有自己的獨立空軍，只是有的強一點，有的弱一點。從某種程度上來說，存在一定的重復(fù)建設(shè)問題。假如全國有一個統(tǒng)一的“空軍服務(wù)中心“，可以按需向各集團(tuán)軍提供轟炸機(jī)轟炸服務(wù)、殲擊機(jī)格斗服務(wù)、運輸機(jī)運輸服務(wù)等，那就可以集中力量把一件事情做好，而不必分散在各集團(tuán)軍。

而這個“空軍服務(wù)中心”就可以稱為面向全軍的空軍中臺。

陣地戰(zhàn)早已成為過去，現(xiàn)代戰(zhàn)爭的趨勢是小部隊滲透、游擊戰(zhàn)、特種戰(zhàn)。雖然是小部隊，但其身后是強大的中臺做支撐。這也是“大中臺小前臺”的思想。而在互聯(lián)網(wǎng)領(lǐng)域，市場機(jī)遇瞬息萬變，誰能以最快的速度小成本快速試錯誰就能取得市場先機(jī)。

舉一個Web開發(fā)框架選型的例子。曾經(jīng)問過師兄一個問題，為什么公司(前東家)還在用Webx這樣的有十幾年歷史的老古董框架而不用現(xiàn)在流行spring mvc? Webx雖然歷史久遠(yuǎn)，但其核心思想是"約定勝于配置"。也就是說框架把基本的事情都規(guī)定好了，比如文件放在什么位置、代碼基本邏輯該怎么寫。如果不按照約定，應(yīng)用根本啟動不起來。留給工程師可自由發(fā)揮的空間較小，所以絕大多數(shù)的應(yīng)用都是一樣的，學(xué)會了一個其他的只需要了解一下業(yè)務(wù)邏輯即可快速上手，學(xué)習(xí)成本接近0。

舉個例子說下這樣做的好處，比如同學(xué)A休假了，同學(xué)B臨時補位。趕巧這一天線上異常了，同學(xué)B在不了解應(yīng)用的情況下，根據(jù)出問題的URL就可以很快定位到出問題的代碼。

相反，spring mvc提供給工程師可自由發(fā)揮的余地就太靈活了。在工程師個人效率最大的情況下，團(tuán)隊整體效率反而是最低的。相比，Webx犧牲了工程師部分的個性，換來了整體效率的最優(yōu)化。

讀下來，好像本文的觀點是“扼殺工程師的選擇空間和創(chuàng)造力”。我覺得最終還是要在“個人效率最大化”和“團(tuán)隊效率最大化”之間做好trade off!