又是一年D2：頗具匠心的中台技術修養

YMFE 資深工程師，負責去哪兒網 Hybrid（Hy）、React Native（QRN）等移動端方案架構、開發和推進，專註於移動前端，著眼於工程流程化。

杭州、西溪、冬、煙雨朦朧，又是一年阿里 D2。同樣的會場，同樣的人，但卻是不一樣的感受。

這屆 D2 的主題是「匠心」，令筆者最為觸動的詞是「中台」，而筆者今年關注了 D2 新加入的主題 「前端技術管理」，關注了團隊與個人的「技術修養」問題，因此，結合幾個關鍵詞，給這篇文章起了一個比較文藝的題目《頗具匠心的中台技術修養》。

與以往不同，由於在團隊中身份的轉變，這次來 D2，對業界方向的關注要遠超於對前端技術細節的關心，因此，「技術管理」和「技術方案的整體設計」是這次筆者所重點關注的。

第一小節 —— 成長

經過幾年的發展，前端的技術成熟度和穩定性已經到了一個很高的水平，雖然各種輪子層出不窮，但是技術體系和架構已經趨於穩定，這個時候，如何管理好團隊使用的技術棧，既不「故步自封」，也不「橫衝冒進」，是現在前端團隊、終端團隊管理者需要重點關注的問題。而今年，D2 也推出了前端管理的主題，幾位有豐富經驗的前端團隊 Leader 向大家分享了他們的經驗。

其中，讓筆者感觸最深的是月影帶來的 《自我成長的多元化團隊》。筆者從之前的單打獨鬥，到現在帶領團隊一起奮戰，團隊成員的成長一直是筆者花費很大精力去關注但成效不多的地方，而遇到的問題大部分都在月影的分享中被提到，因此感觸頗多。其中「多元化」和「閉環」是其中筆者覺得最為核心的兩點。

在一個團隊內，包含著風格、性格、能力各不同的成員，如何讓每個成員都能體現出應有的價值，一直是團隊 Leader 所遇到問題中的比較棘手。尤其是向筆者所在團隊 YMFE 這樣的負責公司大前端礎架構與中台方案的團隊中，每個成員體現的價值與其能力有時候相差甚多。再加上，團隊每年都會招入一些沒有什麼業務經驗的應屆生，如何讓應屆生表現出其突出的價值，以致讓團隊認為其值得培養，並傾斜資源，也是件很鬧心的事情。

在這裡，月影提出一個觀點 ——「重組織、輕管理」，對每個人單獨的管理不如更宏觀地規劃處一系列的 「大道」，讓成員自行選擇。當然，這裡的一系列 「大道」肯定要滿足兩個條件，就是上文所說的「多元化」和「閉環」（下圖是奇舞團的多元化、多維度的成長空間）。雖然，當前團隊也有類似的 「大道」，但是維度並不足夠；而且，當團隊發展到一定的規模後，低維度的成長空間會可能會制約團隊成員的行動力，所以，根據公司、團隊自身情況建立不同的成長空間、成長路線是很有必要的，或許這將是筆者 2018 年在團隊內主要推動的事情。

相比於「多元化」，筆者感覺「閉環」 其實更為重要，不論是「正面反饋」 還是「負面反饋」 都是很有必要的。在一個純技術團隊中，成員自身的技術肯定在第一位，在技術之外，項目管理、新人導師、對外技術輸出和分享等，都是很重要的。而在這些之中，尤其是「對外技術輸出和分享」 最難形成閉環，最難給從事者足夠的反饋。有人說，形成閉環很簡單，直接和績效、晉陞掛鉤。當然只是一種方法，但它只能給成員壓力，例如未完成時的「負面反饋」，而並沒有帶來更多的「正面反饋」。

其實，增加團隊影響力，讓團隊成員都有團隊自豪感，是最好的回饋方式。雖然這一年，團隊也搞了 Conf 會議，同時也有一些開源項目，但筆者覺得收到的 「正面反饋」並沒有預想的那麼多，尤其對低級別和新加入的成員。這不僅僅要在形式上下功夫，更要加強團隊中每個人的團隊意識，這應該是下一年需要重點提升的。

第二小節 —— 務實

在月影的分享中，有關管理者「積極」和「保守」的問題，也令人深省。

不管是積極的管理者還是保守的管理者，都很看重優秀的人才和高效的組織，因為優秀的人才加上高效、穩定的組織，才能形成一個優秀的團隊。關於這點，絕大多數人都知道，並且有一定的認識。所以，筆者在這裡就不多做贅述了，而談一下，對前三點的看法和思考。

首先，對於「保守」 這個偏貶義的詞，筆者認為用「務實」更為貼切。直白點說，工資是公司發的，給公司創造價值才是當務之急，把技術用於業務、用於產品，減少業務的風險，或許是公司管理層更願意看到的。打個比方，即使寫了一個前無古人後無來者的無敵框架，如果不被業務所採用，到頭來產出的也就那麼幾千行代碼而已。

這裡，可能讀者會認為筆者是個偏 「保守」的管理者，其實並不是。筆者是個大白羊，一往直前的創新絕對是不可磨滅的慾望，但是筆者更傾向於在 「保守」的基礎上「積極」，在「務實」的肩膀上 「創新」。創新是著眼於未來，但你的創新是否對未來有效，卻不能空口無憑。因此，所謂的創新要在務實的場景中提煉，提煉出未來所需要的創新。講一個很簡單的邏輯，在務實業務的過程中，發現了業務的痛點，需要一種新方式來解決，因此去創新。這樣能保證你的創新不管結果怎樣，出發點是有意義的，是可以被大家認同的。就像 React Native，它解決了業務急需熱更新的需求的同時，提升了體驗，做出了比 Web 更好的體驗效果，因此受到了大家的青睞。而現在，React Native 的劣勢也表現出來，例如，因為通信的瓶頸，List 的效率堪憂，再例如，Native 實現的組件不能熱更新（至少 iOS 不行），這種情況下，我們又要如何去解決了？是做微創新，直接切入痛點，解決問題；還是做大創新，提出一個比 React Native 更好的架構形式，這才是管理者應該去深入考慮的。

第三小節 —— 中台

在上面的敘述中，筆者提到了「中台」這個詞，並把團隊的部分工作稱為 「中台方案」。其實，「中台」這個詞，筆者是在 D2 上才關注到的，因為很多分享都提到了「中台」這個概念，也可能是因為分享人大多是阿里系的有關。「大中台，小前台」是阿里巴巴在 2015 年底提出的公司級戰略，之後很多公司效仿，讓很多之前的「公共支持團隊」變成現在的「平台事業部」。公司戰略層面的高深意義不是筆者一個小技術人員能理解的，不過，僅限技術而言，這樣的戰略，會減少多團隊干一件事的概率，同時也讓想做技術的同學可以一直單純的做技術，不用去想「30 後做管理，40 後當經理」的事情。這或許是，單純喜歡做技術的同學一個福音吧。（下圖是 2016 年初阿里基於 「大中台、小前台」戰略制定的集團整體組織架構）

中台是什麼？給前台提供工具、服務、模塊等公共、統一化的資源。對於大前端技術來說，構建工具、開發平台、服務平台、公共組件都算作中台的範疇。在大前端基礎架構趨於穩定的情況下（前端 React、Angular、Vue 三分，客戶端原生、Hybrid、React Native（包括類 RN）三分），除了基於現有架構，適配自身公司的基礎研發外，更多的是，給業務提供技術方案支持，讓業務方更快地進行開發迭代，這或許是當前大前端重點要做的。

當然，唯「中台」論，有時候也比較「可怕」。當前台的技術人員只關心業務，同時中台的技術人員不能提供滿足前台的技術需求，這將是很可怕的一件事，因為很難彌補中間的空缺，或者這個問題成為拉鋸戰。因此，作為「中台」部分的工程師，要承受更大的壓力，並擁有更深的技術。

第四小節 —— 修養

在「大中台，小前台」的環境中，大前端工程師，要有怎樣的技術修養呢？直接貼盒馬岑安的三張 PPT。

「以史明鑒」一直是很好的分析方式。通過回顧前端的發展歷程，每個階段的技術，都是為了解決這個階段的難題與痛點。雖然說，圖中跟多是前端的內容，但是客戶端與之是類似的。因此，可以說，大前端已經解決了從內容承載到體驗優化，在從副交互到工程化，甚至包括開發模式等各個方面的問題，而解決這些問題的能力是當前大前端工程師的基本要求。

而現在呢？未來呢？筆者談談自己的想法。在業務形式不斷擴展，「中台」變大的時代，大前端工程師，尤其是做架構的大前端工程師，更多地需要能耐得住寂寞。不同於前幾年，一個優秀的架構方案，可以翻江倒海；而現在，包括將來，要做的更多是為業務提供服務的工作，穩定和完善是關鍵。或者，你可能已經感受不到獲得感，但是你做的東西的實際價值或許會更高，因為它會支撐比現在更多的業務。

最後，貼一張 「核心競爭力」的 PPT —— 不僅僅要拆解後輸出，更要落地於業務。

第五小節 —— 更好

作為中台特徵明顯的大前端架構，究竟要做什麼？或許是，更完善的生態和更好的服務。

很簡單的一個道理，當人吃飽了，就會要求吃得好、吃得方便、吃得有營養了。做架構也一樣，當架構可以滿足業務需求後，業務就會反過來，要求架構更穩定、更易用了。

上面是 支付寶加里分享了一張 PPT，類似的 Q 還包括很多，「為什麼代碼還是原來的」、「為什麼點擊沒反應」、「iOS 沒毛病，Android 掛了」。對於這類繁多的業務人員反饋的問題，是煩人也棘手的；你不能奢求業務人員去自己解決，況且有些問題，業務人員根本解決不了。在這時，你就需要一個完善的工具、服務等等其他的一些東西，來快速定位問題，或者來證明「問題不是框架的，是業務自身的」。因此，在未來一年或者幾年，對於中台、對於大前端的架構團隊，更完善的生態和更好的服務應該被首要關注的。

總結

2017 仍是大前端火熱的一年，但發展也已經從「野蠻生長」變為「頗具匠心」，越來越多穩定成熟的架構方法被廣泛使用。與此同時，時代的熱點已經轉到機器學習和加密貨幣，而主項是 UI 的大前端發展又將何去何從呢。或許歷史已經給出答案，傳統後端默默地做了許久的模塊化、服務化，伴隨著雲的興起，又迎來新一春。或許，大前端的「中台化」，是大前端發展接下來最重要的一步。

2018，新的一年，你好。

D2 更多視頻 和 PPT 信息，請訪問官網：http://d2forum.alibaba-inc.com/

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！