阿里妹導讀：前端是個資源型角色，在認知里對業務的理解深度不夠，加上通常負責業務領域很廣，比較難有積累和沉淀。如果問一個畢業10年的JAVA老司機，他跟你談的一定是大流量下的分布式架構，而前端可能還是昨天茶余飯后討論vue和react，或者是angular誰更強。

如何突破？如何提供業務更多價值？前端們一直在苦苦探尋。網上很多文章，給人啟發，但每個人面對的環境，負責的業務不同，不一定都適用。今天，阿里巴巴高級前端技術專家城池將結合自己過去幾年在阿里云的前端經驗，做個總結。

1.0 版本——工具&團隊

今年是我來阿里云的第五個年頭了，從沒有想過會在一個公司呆的如此之久，更沒想過我能在一個崗位上沉淀4、5年。剛入職在阿里云控制臺團隊，主要負責云盾控制臺、drds控制臺等，開發過程中發現大部分場景是「表格」、「表單」，為了避免自己不斷重復開發，封裝了simpleForm以及控制臺cli腳手架，可以做到新開發控制臺一鍵敲定(這個腳手架直到去年還有人問我如何用……也是經久不衰)。

后由于組織結構調整，我從控制臺團隊獨立出來，負責當時的網站運營方向，開始比較艱難地從0-1組件團隊過程。當時業務相對比較簡單，主要是：阿里云官網以及官網的Nodejs、云市場業務。由于在控制臺團隊主要用的angularjs，感覺上手成本比較大，在建立新團隊，以及我自己可以選擇的時候，React成了我的首選。當時vue還沒成熟，其實能選的也只有react。

新的技術體系，需要有配套的工程化體系，當時Def還處在1.0時期，為了穩定以及減少開發成本，很自然我們在xef上做了插件式開發，結合自己業務特性，分裝了響應的模板，以及定制了開發周期。

后由于xef1.0升級2.0，導致我們工具的不穩定，且改動非常大，逐步將我們的工程化體系獨立，這就有了后續的DBL（當時叫屌爆了）。我跟老板做匯報時，老板覺得這名字上不了大雅之堂，還硬是憋了個比較有內涵的名字——實在不好記，我現在都記不起來了。

這個階段，我們做了很多技術上的嘗試，團隊成員都非常有激情。團隊基礎設施建設，我們一直在優化，隨著Dawn的基于中間件式的pipeline方式設計，可以說是將工程化做到一個比較高的高度，未來不管是webpack升級到多少，或者新的打包工具出現，對我們來說影響都比較小。

面向未來的模式，讓我們只需要修改內核，使用者無感知。同時，新的方案也完全遵循集團的標準。另外還有一個好處是：dawn不局限在react，你可以使用任何框架；dawn不局限在redux，你可以使用任何你喜歡的數據管理，實際上我們自己有用mota，mobx，graphql-apollo等等【1】。

除了折騰傳統前端領域，也嘗試做了很多跨棧的事情。在我所負責的業務中，由于「端」業務的確實，我們更多的是偏「全棧」。前端同學做全棧，講實話是不行的——絕大部分前端同學在架構、運維部署方面還是經驗偏少，考慮更多的是跟展現層相關。

在全棧路上，我們主要有兩個策略：

• 大前端下自己寫部分業務的Java
• 利用serverless通過代理統一配置化轉

通過以上的技術基礎建設，已經為我們構建了很好的基礎。業務布局對應著團隊、組織的建設。過去幾年，團隊從0到1建設，到目前N個在崗同學，形成了四個梯隊，三個業務方向&一個技術架構方向，一路走來，感覺帶團管理水很深，很多時候不是說你帶的人越多越好，最近看到一本書提到一個詞「情感成熟」，這個非常重要。一個技術好，做業務的好手未必能管理好團隊，在不同階段需要適應不同角色的要求，最重要的是時刻保持憂患意識、保持持續學習。在團隊建設時，需要重點區分manager和leader，尤其是業務團隊我們更希望成為leader，去帶著做業務，而不僅僅是做績效管理。

過去一年，我們在業務思維指導下，owner了部分業務，并利用橫向的技術打通、橫向的業務思維，取到了一些成果，接下來進入2.0。

2.0 業務思維——以橫向視角推進業務賦能

我們通常把組織中的人分為：“一”字型、“|”字型、“T”字型、“+”字型。前端正好是—字型團隊，負責的業務非常廣，而前端又是個非常稀缺的崗位，招聘很困難，所以盤子越大資源瓶頸越明顯。「一字型」角色團隊，典型的問題就是對業務的深度理解不夠，單純從技術層面去做營銷的搭建、中后臺的可視化，結果都不盡如人意。這么說起來，可能你覺得沒法往下看了，天花板在那里，如何突破其實并沒有太多可參考的例子。我寫這篇總結，正是有些這樣的感悟，希望給大家做一些輸入，幫助大家去思考。

「一字型」雖然從業務上看我們的深度不夠，但從專業技能看我們是標準的「 | 字型」。前端經過這10來年的發展，語言、框架、工具已經逐步趨于穩定，各種端的性能也越來越流暢，生態非常活躍，任何你碰到的困難相信社區都已經有比較成熟的方案。前端生態快速發展的10年，也驗證了我們這些人有著非常強大的學習能力，7天一個框架、3天一個數據庫估計都不是太大難事(略夸張，但表達的是這么個意思)。前端直接對接客戶，對客戶體驗的敏感、對流程數據化的敏感、對業務邏輯流程的感知，都是我們生存的根，也是我們獨一無二的能力，這個根我們不能丟。

在前端縱深領域的深耕，讓我們成為了「緊缺資源」，隨著工具的完善，前端們也更希望利用技術為業務賦能。如何賦能？擋在我們面前的是「意識」。

在營銷中，認知、需求、品牌、品類、價格五個要素中，「認知」最為重要。許多一線互聯網公司在自己主營業務范疇不斷布局，構建了龐大的生態，做過很多嘗試，但看起來最終還是圍繞本身的基因做生態投資成功率要高一些。那我們想要業務賦能，瓶頸就在于「你個切頁面」也要賦能嗎？好好做好體驗、提效不好嗎？我認為「體驗、提效」這是前端最核心的能力，也是畢生都努力要實現的目標，坦白講我們沒法馬上解決資源瓶頸問題，畢竟現在畢業生都在應聘算法、AI、人工智能；我們也沒辦法搞一輪體驗提升計劃；這是個很漫長的過程。

但如果我們能以業務的角度出發，去發現問題進而輔助以技術手段解決，并沉淀平臺，應對未來千變萬化的需求，可能更為實際一些。做為團隊的TL，除了在專業上給與同學「|」型的能力縱深，也更希望帶著團隊同學獲得更多業務體感。離開業務談技術、談中臺都是空中樓閣；離開業務談前端，注定只能是重復造輪子，而這種低水平的重復正在發生，且可能會持續很久。

在很長一段時間里，我都試圖把我們「一字型」業務廣度做個抽象和融合，希望把「點狀」形成「線」，進而形成整體「面」解決方案。我所負責的業務中，主要有4個大方向：

• 官網&營銷——for長尾
• 商業化流程后臺——for小二
• 核心售賣流程——核心能力層
• 銷售、合作伙伴

官網&營銷：主要包含獲客、激活、轉換、留存幾個節點，構建高效的「人」、「貨」、「場」。很長一段時間里，阿里云的內容維護、營銷大促都是基于集團CMS來的。傳統大促會場、卡片的方式，前端挖坑后運營編輯內容，而阿里云的「商品」跟淘系有著比較大的差別。

另外，我們也沒有招商、選品的體系，導致這種簡單人肉運行的大促方式存在很多弊端，比如：不高效、不復用、不能做個性化、數據流程監控力度不夠精細等。此外「投放」能力的建設還不夠，沒有辦法做到精細化的人群做精準的營銷內容投放。為了解決這些問題，去年開始，由前端團隊和pd一起推進完善的營銷體系建設：

• 在原有商品的基礎上，構建了「營銷商品」的概念。更抽象的「貨」，且可視化在線配置直接拉取了實時價格和庫存。通過我們1.0工具建設的dawn，打通開發流程，使得整個開發鏈路一致，成本更低。可抽象的貨匹配上專門為貨打造的UI視圖，形成場景能力沉淀。
• 構建ACE(Alibaba Cloud Experience)架構體系，打通搭建體系，通過技術降級打通各類「場」，更好地承載好營銷商品的投放。
• 通過全鏈路場景的曝光、點擊、轉化，以及最終成交的商品信息等數據的積累，生成用戶畫像，提供內容場景化方案（在不同場景中精確得向用戶展示商品或信息)完善「人」的定位。

商業化商品配置：上面提到「營銷商品」時提到「基礎商品」。目前阿里云基礎商品主要分為：「公有云商品」和「技術輸出型」。過去很長一段時間我們偏公有云的能力建設，今年年初才開始逐步融入專有云體系。

在商業化系統中，我們的小二需要配置售賣規則、價格，需要定義商品模型；同時復雜的規格之間的約束，異常復雜。如何提高商業化的輸入和輸出的強體驗，我們還有很長的路要走。結合今年的專有云項目，從模板的方式出發，將一類產品做個聚合，簡化商品模型配置的步驟，大大提高了配置效率，提高體驗。

銷售&合作伙伴：15年剛開始組建團隊(這里指的都是前端團隊，不是業務團隊)，15年 - 18年3月大部門的核心KPI是營收、是首購用戶數，主打的是中長尾客戶，獲得了非常高速的市場增長。

后來團隊cover范圍不斷擴大，也負責銷售&合作伙伴體系，圍繞著「市場營銷」、「商機培育」、「商機轉化」、「合同履約」構建了我們自己的銷售CRM系統。To C的業務通常比較好理解，畢竟我們也是C的一員，這段to B的經歷，結合業務一號位的培訓班，讓了解到銷售系統的核心，除了工具，最想要的是解決方案，是產品能力的豐富。

大概介紹了各個方向的業務，回到我們討論的主題來——借助橫向優勢，整合資源&架構提供業務賦能。為了分析他們之間的共性，我們經過很多次的討論，終于匯聚得到我們的業務流程大圖：

從這個流程大圖中，各個分支最后都需要依賴「售賣能力」，售賣能力不同場景中有不同表現：

• 表現在營銷中是「彈窗buy(減少跳出，直接購買)」、購物車(多產品交叉購買、數據算法推薦)、套餐(多產品打包優惠售賣)、提貨券(下單和生產分離的售賣能力)；
• 表現在銷售鏈路中是「產品配置清單」、「采購單」、「CBM提供給大客戶的CTO價格計算器」；
• 表現在商品商業化鏈路中是「模板化」配置清單能力。

在一大團子中找到業務的共性「售賣能力」，在經歷一段時間比較耗資源、耗時的煙囪式開發方式后，抽象出了售賣的核心支持層——紫金闕。這一層，我們定位為業務中臺，偏前端層面，也是大前端的領域范疇。唯一需要指出的是，我們用的是Java，沒有用nodejs，無其他差別。最后架構如下：

新的架構模式下，我們減少了大量的前后端溝通，比如「分銷采購市場」以傳統開發方式需要1-2個月，我們2周就搞定了。新的架構模式，在可預見的未來，可以很好的支持各種營銷新玩法，也可以支持銷售和合作伙伴的「解決方案」。

我想說的是，如果沒有我們全量業務的橫向視角，我們的抽象方案不會這么通用，這是前端團隊的優勢。如果沒有大前端穩定的技術生態，我們也沒機會去做業務賦能。這才是前端的未來，利用橫向優勢整合，結合某個領域做深做透，形成垂直深度，為業務提供價值，也讓我們的技術方案「有的放矢」。前端經常是圍繞一個點做需求，得到工具，但無法提供解決方案，因為沒有業務屬性；唯有結合業務特性，做好沉淀，工具變成平臺才能釋放更大價值。

3.0探索以技術能力為業務提供增值

「云計算」核心是解決企業成本的問題，用低成本獲得超強的計算、存儲能力，獲得高并發下彈性擴容的能力。云計算提出了很多概念：IAAS、PAAS、SAAS等，相對前端角色來講，體感并不是很強。但是BaaS的出現，讓前端眼前一亮。

試下想，原先我們需要大量后臺開發的應用，逐步都沉淀成領域能力，提供BaaS服務給前端調用，前端再也不用考慮部署、運維，只關心業務代碼，想想也是心動。目前市面上提供類似服務的公司很多，有專門做后臺數據存儲的如Leancloud、有做數據分析的、有做消息推送的等。所以，BAAS會是前端的春天嗎？這個拭目以待。

扯了理想，我們也說說現狀。目前阿里云大概是Buy In Aliyun，我們售賣的是IAAS層的資源，用戶核心的業務流程還是基于自己的研發體系。在前端這個縱深領域內，基于云打造「云端一站式研發流程」，將企業前端變成：Work In Aliyun or Dev In Aliyun。通過對企業前端生命周期的分解，通過WebIDE來承載整個流程：

1. 將創建關聯阿里云的code

2.阿里云前端構建工具dawn作為基礎構建能力。

可定制化團隊構建的中間件(webpack、lint、server、mock等)、構建stage(init、dev、test、publish)；基于工程化化能力提供統一的規范，提供各種不同應用框架的初始化模板。

3.代碼點擊發布后，自動編譯，并發布到cdn。

在此基礎流程之上，我們提供serverless相關能力，通過調用BaaS領域服務能力，以及FaaS網關觸發能力，實際上我們可以完全一站式，且是前端主導的應用開發。

前面提到我們的serverless應用「云查詢」，這一層我們逐步進行能力下沉，變成serverless基礎能力。各公司幾乎都有營銷搭建體系，過去搭建的玩法不夠多樣，主要依托cms能力自行開發，隨著現在各種「端」能力的延伸、多樣性化，營銷搭建也變得越來越復雜。而我們基于「云查詢」之上沉淀出的「頁櫥」搭建體系，完全可以借助「云端一站式研發流程」提供很好的SAAS化服務。這是我們的優勢，「云端前端解決方案」也只有我們適合做這個，這里只列舉了其中一個場景，類似的機會還有很多。

總體感覺，一云多端借助serverless前端的春天已然來臨。抓住我們核心的競爭力，并同時發現業務中的問題，跨端推進解決，這是最好的出路。你問我做什么的，我…… 我就是阿里云CPO（首席頁面仔啊）。

原文發布時間為：2019-04-22
本文作者： 城池
本文來自云棲社區合作伙伴“ 阿里技術”，了解相關信息可以關注“ 阿里技術”。

總結

以上是生活随笔為你收集整理的在阿里云做前端，是种怎样的体验？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。