1. 前言

對(duì)于一個(gè)團(tuán)隊(duì)而言，規(guī)模越大，對(duì)于標(biāo)準(zhǔn)化，統(tǒng)一化的需求也就越發(fā)強(qiáng)烈。而傳統(tǒng)軟件行業(yè)中技術(shù)團(tuán)隊(duì)因?yàn)槠渥陨硖攸c(diǎn)（傳統(tǒng)軟件行業(yè)中技術(shù)團(tuán)隊(duì)的發(fā)展(現(xiàn)狀篇)），對(duì)于標(biāo)準(zhǔn)和統(tǒng)一的推進(jìn)處于一種游離態(tài)：

1. 承認(rèn)規(guī)范和統(tǒng)一很重要，但實(shí)際執(zhí)行時(shí)卻總是不斷讓位于迫在眼前的業(yè)務(wù)壓力。
2. 建立的標(biāo)準(zhǔn)紙面化，規(guī)范訂立出來之后，萬里長(zhǎng)征就算是要到盡頭了，剩下的就只需要下面這些組員遵照著執(zhí)行就得了，這點(diǎn)小事就不要再來煩我了，這一塊的問題就算是解決了。
3. 標(biāo)準(zhǔn)的推陳出新。針對(duì)某類問題，得出個(gè)規(guī)范來協(xié)調(diào)各方的操作規(guī)范，過兩天覺得另外一種方式好像更好，咱們要不試試那個(gè)？

“大幅降低團(tuán)隊(duì)的溝通成本，減少系統(tǒng)的維護(hù)成本”，這些標(biāo)準(zhǔn)化和統(tǒng)一所能帶來的好處，并不能讓"統(tǒng)一"這件事自行發(fā)生，我們需要結(jié)合自身團(tuán)隊(duì)特點(diǎn)，通過不斷對(duì)比理想和現(xiàn)實(shí)，制定循序漸進(jìn)的實(shí)施路線。

本文接下來的部分，我們探討傳統(tǒng)軟件行業(yè)中，技術(shù)團(tuán)隊(duì)如何切實(shí)做好技術(shù)棧統(tǒng)一。

2. 歷程

過去這些年，面對(duì)技術(shù)棧不統(tǒng)一，同一類技術(shù)問題反復(fù)解決，各自為戰(zhàn)的狀況，我們按照時(shí)間順序，嘗試了多種方案。

2.1 平臺(tái)化

傳統(tǒng)軟件項(xiàng)目特點(diǎn)是項(xiàng)目規(guī)模小，周期短，數(shù)量多；這類背景下，基于開源組件搭建一套通用的解決方案平臺(tái)， 之后以此為基礎(chǔ)，在新項(xiàng)目中推廣和迭代這套平臺(tái)，寄希望于實(shí)際項(xiàng)目的歷練，將絕大部分解決方案直接集成到平臺(tái)里，最終實(shí)現(xiàn)理想中的搭積木式開發(fā)模式。
不過理想很豐滿，現(xiàn)實(shí)很骨干，實(shí)踐中我們發(fā)現(xiàn)這種單一的方式存在諸多問題：

1. 傳統(tǒng)軟件行業(yè)項(xiàng)目開發(fā)周期確實(shí)短，但維護(hù)周期長(zhǎng)，導(dǎo)致平臺(tái)在優(yōu)化過程中，要不斷考慮兼容既有版本的問題。
2. 業(yè)務(wù)需求緊急導(dǎo)致項(xiàng)目組與平臺(tái)維護(hù)之間容易面臨利益沖突，經(jīng)常出現(xiàn)項(xiàng)目組等不及平臺(tái)的改進(jìn)而自行選擇實(shí)現(xiàn)方式，而當(dāng)這個(gè)項(xiàng)目組被安排接手另外一個(gè)項(xiàng)目時(shí)，他們很大可能不會(huì)選擇基于最新的平臺(tái)版本，而是選擇他們之前已經(jīng)熟悉的那個(gè)舊版本，也就是平臺(tái)版本出現(xiàn)自行分支，并隨著時(shí)間的發(fā)展不斷增加。
3. 平臺(tái)無專人負(fù)責(zé)維護(hù)。平臺(tái)維護(hù)名義上雖然是指定給了某幾個(gè)人，但實(shí)際上這份職責(zé)十有八九屬于兼職，這導(dǎo)致平臺(tái)發(fā)展缺乏規(guī)劃，解決方案思考深度不足等問題，隨著時(shí)間的發(fā)展，平臺(tái)越來越復(fù)雜，脆弱。
4. 平臺(tái)化這一解決方案粒度太粗。平臺(tái)作為大一統(tǒng)的解決方案集合，已經(jīng)接入的項(xiàng)目組不可能因?yàn)槟硯讉€(gè)新增功能或優(yōu)化選擇進(jìn)行平臺(tái)升級(jí)。平滑遷移誘惑巨大，但其中涉及的巨量精力投入對(duì)于傳統(tǒng)軟件行業(yè)技術(shù)團(tuán)隊(duì)而言，性價(jià)比并不高。
5. 以上這些問題交織在一起，相互影響，導(dǎo)致平臺(tái)的演進(jìn)舉步維艱，慢慢地各方都開始刻意回避與其的交集。

2.2 組件化。

針對(duì)上述平臺(tái)化的種種弊端，我們很自然地想到通過減小版本更新影響范圍，來快速響應(yīng)需求。解決方案組件化也就順理成章地提上日程。

這一步在試行過程中，也是碰到了一系列問題：

1. 依然是業(yè)務(wù)緊急下的短期利益與長(zhǎng)遠(yuǎn)利益的沖突。
2. 組件化雖然將版本更新的粒度細(xì)化，但版本更新，平滑升級(jí)等這些問題并沒有被解決。平臺(tái)化遭遇的那些問題，組件化并沒有幸免。
3. 組件化加快需求響應(yīng)速度的同時(shí)，也讓組件與既有項(xiàng)目之間出現(xiàn)沖突的可能性大大增加。
4. 臆想中的主動(dòng)參與組件維護(hù)人員并沒有出現(xiàn)。

2.3 文檔化

平臺(tái)化和組件化的效果大幅低于預(yù)期，這一現(xiàn)實(shí)讓我們不得不重新審視團(tuán)隊(duì)：

1. 傳統(tǒng)軟件行業(yè)技術(shù)團(tuán)隊(duì)中，對(duì)研發(fā)人員的約束力并不強(qiáng)。薪資的吸引力，以及業(yè)務(wù)壓力等諸多影響因素，負(fù)責(zé)人與組員之間就進(jìn)度和質(zhì)量商量著來的現(xiàn)象并不鮮見。
2. 部門主管對(duì)項(xiàng)目團(tuán)隊(duì)施加技術(shù)影響的機(jī)會(huì)其實(shí)很有限。除了最開始確定項(xiàng)目技術(shù)框架，以及某些項(xiàng)目組遇到無法快速解決的技術(shù)問題外，其他時(shí)間領(lǐng)導(dǎo)即使有心，也只能感慨無力回天。

以上這些原因，加上平臺(tái)化和組件化下暴露的種種弊端，讓我們開始正視一直被我們刻意回避的方式：解決方案文檔化。

之所以一直回避這個(gè)方案，原因其實(shí)很容易想到：

1. 很少有人喜歡寫文檔，即使已經(jīng)在理智上百分百贊同文檔的重要性。
2. 偷懶，想走捷徑。對(duì)，不論如何粉飾，根源其實(shí)都是它。我直接把方案整成代碼，然后告訴你怎么調(diào)用就完事了。

而解決方案文檔化的優(yōu)勢(shì)，總結(jié)下來：

1. 老生常談的沉淀。文檔更容易讓一類問題的多種解決方案共存，并將選擇權(quán)交給使用者，這可以大幅降低使用者的抵觸，也能潛移默化地對(duì)使用者進(jìn)行影響，讓他們參與到文檔化的建設(shè)中來。
2. 傳統(tǒng)軟件行業(yè)技術(shù)應(yīng)用程度淺，重復(fù)率高等特點(diǎn)也使得文檔化的工作量并不大，且ROI頗高。一般四/五輪迭代之后，某類解決方案就只剩下機(jī)械式地復(fù)用了，慢慢地問題解決方案也就統(tǒng)一了。
3. 相較于平臺(tái)化和組件化這兩種方式要求比較高的技術(shù)水平，文檔化則是真正的全民參與。遵循“你的疑問不是第一個(gè)，也不會(huì)是最后一個(gè)”，任何人只要有意愿，都可以作出貢獻(xiàn)，而且這類貢獻(xiàn)屬于與技術(shù)能力關(guān)系并不大，有助于團(tuán)隊(duì)的全面發(fā)展。

2.4 階段性小結(jié)

縱觀以上演化歷程，其實(shí)就是一個(gè)不斷被迫直面現(xiàn)實(shí)，解決問題的過程。

1. 一開始就想要進(jìn)行平臺(tái)化建設(shè)，就是寄希望于一次性解決所有問題；之后的組件化，文檔化則是在意識(shí)到一步到位不現(xiàn)實(shí)之后，逐步調(diào)整得到的方案。
2. 事物的發(fā)展有著其內(nèi)部自有規(guī)律。技術(shù)發(fā)展確實(shí)可以讓后來者享受紅利，讓后來者以更快速的速度翻越前輩曾經(jīng)遇到的高山，但這并不意味著你可以直接省略這些步驟。

3. 究其原因

針對(duì)上述歷程中遇到的問題，讓我們嘗試匯總下其原因：

1. 項(xiàng)目需求不斷演進(jìn)的同時(shí)，平臺(tái)本身也在發(fā)展，沒有專門的團(tuán)隊(duì)維護(hù)，平滑過渡本身也是一個(gè)非?？简?yàn)個(gè)人和團(tuán)隊(duì)能力的要求，破壞性升級(jí)之下導(dǎo)致小組很容易在已有基礎(chǔ)上修修補(bǔ)補(bǔ)，平臺(tái)優(yōu)化各自為戰(zhàn)，發(fā)展進(jìn)入停滯。
2. 歷史原因造成各項(xiàng)目技術(shù)框架依賴不一致， 導(dǎo)致雖然都是屬于平臺(tái)內(nèi)解決方案，但無法保證升級(jí)的平滑，很容易出現(xiàn)依賴沖突，缺失等問題。
3. 既有人員對(duì)熟悉技術(shù)的固守。如果研發(fā)人員熟悉了某類問題的一種解決方案，那之后如果不強(qiáng)勢(shì)介入，十有八九這個(gè)方案會(huì)落到他經(jīng)手的每個(gè)項(xiàng)目里，即使針對(duì)這類問題框架里已經(jīng)存在。
4. 指導(dǎo)性/監(jiān)管力量不足，底層則會(huì)恣意生長(zhǎng)，按照自己的思路形成秩序。如果你不能進(jìn)行事前或者事中的及時(shí)介入，一線自己會(huì)尋找問題的解決方案，并且會(huì)在團(tuán)隊(duì)內(nèi)固化該方案。最終敝帚自珍也吧，自私也吧，造成小范圍自嗨，進(jìn)而出現(xiàn)小組脫離整個(gè)團(tuán)隊(duì)獨(dú)自演化的問題，這種場(chǎng)景下平臺(tái)化/組件化/文檔化這些方式都將不再具備任何效果。

4. 如何做到技術(shù)棧的統(tǒng)一：

4.1 平臺(tái)化，組件化，文檔化，三方案并行。

上述三個(gè)方案各有其優(yōu)缺點(diǎn)，為了最大化地覆蓋問題場(chǎng)景，確保持續(xù)推進(jìn)，我們需要綜合應(yīng)用這三個(gè)方案：

1. 平臺(tái)化主要是針對(duì)新項(xiàng)目。傳統(tǒng)軟件公司內(nèi)部培訓(xùn)體系很弱，人員培養(yǎng)基本都是直接在正式項(xiàng)目里邊干邊學(xué)。針對(duì)這樣的特點(diǎn)，在新項(xiàng)目建立之初團(tuán)隊(duì)強(qiáng)制要求以平臺(tái)為基礎(chǔ)，可以快速建立起一個(gè)統(tǒng)一的技術(shù)?；A(chǔ)。
2. 組件化主要針對(duì)歷史項(xiàng)目，用于解決某類問題(例如操作office，附件上傳下載等)，實(shí)現(xiàn)問題的快速響應(yīng)，解決方案的沉淀。并且經(jīng)過多輪考驗(yàn)的組件會(huì)作為默認(rèn)基礎(chǔ)依賴集成到平臺(tái)中，形成互補(bǔ)。
3. 文檔化的受眾也是以歷史項(xiàng)目為主。傳統(tǒng)軟件技術(shù)團(tuán)隊(duì)管理權(quán)限不足的問題決定了很多改變只能用潛移默化影響的方式實(shí)現(xiàn)，而文檔化解決方案正是這一需求的典型實(shí)現(xiàn)，通過提供已驗(yàn)證的，詳細(xì)步驟的解決方案來吸引團(tuán)隊(duì)成員熟悉和使用，進(jìn)而逐步形成針對(duì)某類問題的團(tuán)隊(duì)統(tǒng)一方案，進(jìn)而降低系統(tǒng)維護(hù)成本。

4.2 強(qiáng)化過程檢查

對(duì)于傳統(tǒng)軟件技術(shù)團(tuán)隊(duì)而言，過程檢查基本都是形同虛設(shè)。不論負(fù)責(zé)人，還是實(shí)際的組員，大家都會(huì)非常默契地將系統(tǒng)驗(yàn)證時(shí)機(jī)不斷后延，直到系統(tǒng)馬上要進(jìn)行客戶驗(yàn)收，迫不得已才會(huì)組織少數(shù)幾次集成測(cè)試，至于測(cè)試效果如何？相信大家都有切身感受，“集成地獄”這個(gè)業(yè)內(nèi)鼎鼎有名的詞能夠傳承這么些年，已經(jīng)很說明問題了。

在傳統(tǒng)軟件技術(shù)團(tuán)隊(duì)中推行制度，需要被牢記的一條準(zhǔn)則是對(duì)其執(zhí)行情況的檢查，尤其是在初期，絕對(duì)不能以人工力量的投入作為必要條件。檢查操作里人工占比和制度最終落地的失敗率成反比，人工檢查步驟多一步，制度落地概率就降低一成。

因此，過程檢查落地的最佳實(shí)踐是審視現(xiàn)有研發(fā)流程，找出可能的門禁設(shè)置點(diǎn)——例如代碼提交階段的靜態(tài)質(zhì)量檢查，提交日志格式規(guī)范檢查，非文檔里推薦的問題解決方案的檢查等等，這些機(jī)器自動(dòng)檢查能夠協(xié)助我們?cè)趩栴}發(fā)生初期進(jìn)行及時(shí)的介入，實(shí)現(xiàn)低成本地糾正問題，確保團(tuán)隊(duì)在技術(shù)棧統(tǒng)一的道路上不斷前進(jìn)。

5. 后記

傳統(tǒng)軟件行業(yè)里，對(duì)于技術(shù)棧的統(tǒng)一更多是處于一種間歇性躊躇滿志，持續(xù)性放任自流的態(tài)度。

但這并不意味著傳統(tǒng)軟件行業(yè)里都是不思進(jìn)取之輩，傳統(tǒng)軟件行業(yè)的特點(diǎn)以及真實(shí)存在的人員素養(yǎng)差異確實(shí)讓傳統(tǒng)企業(yè)在技術(shù)體系的構(gòu)建上步履蹣跚，進(jìn)步緩慢。

表面上看不到并不代表改變沒有發(fā)生，一次次的鎩羽而歸只是代表我們當(dāng)下的認(rèn)知與現(xiàn)實(shí)情況不符，只是代表我們需要進(jìn)一步調(diào)整自身來適配當(dāng)下的環(huán)境。

也許你會(huì)不忿，你會(huì)不甘，你會(huì)哀怨自己為何要選擇和這幫人一起共事？ 你會(huì)想要離開，去追逐更好的發(fā)揮才能的地方，這都是人之常情。

但如果因?yàn)楦鞣N原則你選擇留下，那還請(qǐng)不要灰心，不要放棄，既然你已經(jīng)做到了這一步，那為什么不繼續(xù)堅(jiān)持下去，畢竟能夠走到一步的，一定是花費(fèi)諸多額外時(shí)間和精力自我訓(xùn)練，希望不被茫茫人海淹沒的，所謂為了自己心中的驕傲，繼續(xù)尋找破局的辦法吧。

6. 參考

1. 傳統(tǒng)軟件行業(yè)技術(shù)團(tuán)隊(duì)中如何做好知識(shí)沉淀