杭州、西溪、冬、煙雨朦朧，又是一年阿里 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 資訊，請訪問官網：d2forum.alibaba-inc.com/