前言

今年是我畢業的第10個年頭，半路出家做了前端，title一直是前端，你可以說我很專注，有時候也有些遺憾。一直以來，當別人問起你是做什么的，我說前端或者全棧，別人說：哦，做頁面的啊！心里難免有些失落。前端是個資源型角色，在認知里對業務的理解深度不夠，加上通常負責業務領域很廣，比較難有積累和沉淀。如果你問一個畢業10年的JAVA老司機，他跟你談的一定是大流量下的分布式架構，而前端可能還是昨天茶余飯后討論vue和react，或者是angular誰更強。如何突破，如何提供業務更多價值，前端們一直在苦苦探尋。網上很多文章，給人啟發，但每個人面對的環境，負責的業務不同，不一定都適用。結合自己過去幾年在阿里云的前端經驗，也做個總結。

1.0版本-工具&團隊

今年是我來阿里云的第五個年頭了，從沒有想過會在一個公司呆的如此之久，更沒想過我能在一個崗位上沉淀4、5年。剛入職在阿里云控制臺團隊，主要負責云盾控制臺、drds控制臺等，開發過程中發現大部分場景是「表格」、「表單」，為了避免自己不斷重復開發，封裝了simpleForm以及控制臺cli腳手架，可以做到新開發控制臺一鍵敲定(這個腳手架直到去年還有人問我如何用……也是經久不衰)。這個時候也萌生了做個ide，可視化搭建UI視圖，不過限于精力和當時團隊的方向，且當時vscode還沒今天這么流行，沒有嘗試，比較遺憾。不過做WebIDE這個點，算是在心里種下了。

后由于組織結構調整，我從控制臺團隊獨立出來，負責當時的網站運營方向，開始比較艱難的從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等等。

講完工程化，其實應該講講組件化，這是個無法回避的問題，但這對我們來說也是個艱難的過程。15年的時候，我們用過antd（已開源），但是在上層做了一層業務封裝；后來fusion開始盛行，在跟ued溝通后，考慮到集團統一，用了一段時間的fusion（已開源）；最后我們還是選擇了自建組件庫，這是一個很無奈的舉動。具體細節不表，其中一個重要原因是我們的前臺業務需要「阿里云自己的設計元素」，在經過團隊很長時間的建設，APS組件庫已經作為團隊組建庫的基礎，在其之上構建了業務組件，并在之上構建了業務解決方案。

除了折騰傳統前端領域，也嘗試做了很多跨棧的事情。在我所負責的業務中，由于「端」業務的確實，我們更多的是偏「全棧」。前端同學做全棧，講實話是不行的——絕大部分前端同學在架構、運維部署方面還是經驗偏少，考慮更多的是跟展現層相關。在全棧路徑上，由于我們負責的是核心交易鏈路，我們沒有用大家熟悉的nodejs，而選擇跟后端一樣的語言——Java。做這個決策，其實是挺困難的，也是有故事的。原先有個系統，前端同學用Nodejs寫的，但由于業務非常復雜，加上前端一直是個資源瓶頸的角色，一個人干三個人的活，所以這個同學最后搞不定，離職了。這么個系統就變成了后端想接無法接，前端「沒人力」接的狀況，非常尷尬。從那以后，業務系統中就決定了直接使用Java。

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

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

大前端寫Java，阿里云其實非常多的前端都已經具備了這個能力，我自己也有獨立開發幾個系統從0-1上線，分布式部署且支持國際化的經歷。做了一段時間后發現，其實效率上還好，并沒有傳說中nodejs比Java要高效很多的體感.

利用serverless通過代理統一配置化轉，有段時間看社區有部分人提到Graphql，對此產生了興趣，就順便了解了下，通過代理的方式可以將后端數據轉換成前端需要的格式，非常吸引人，也就一下子扎進去。我自己也同時做了Nodejs的版本給團隊同學普及，同時做了Java版本的demo給后端普及。同時了解到b2b的Mbox平臺跟我們想要的能力比較像，找過他們給我們分享，但由于業務系統整個搭建在他們平臺有一定得風險，于是決定了自建代理平臺，這也是「云查詢」平臺的背景。云查詢主要是戰鋒主導并推進落地的，在集團內取得了不錯的影響力，很多BU很多部門去做過分享。在業務上，通過云查詢，我們實現了不用管應用的運維和部署，實現業務邏輯和接口的轉換，并自動擴容。尤其是營銷體系，在元策&隱天和戰鋒得協同下，取得了比較大的效率提升，并支持了阿里云去年的雙十一。

云查詢經過一段比較長時間的發展，我們已經逐步將它作為基礎能力下沉，在云查詢的serverless之上長出了不同的「輕應用」，以支持不同的垂直業務場景。比如：可視化搭建領域「頁櫥」、基于權限&角色的中后臺解決方案「Flex」等；

還記得我之前說過5年前我想做WebIde，沒有開始；2年前，看到其他云廠商有WebIDE，我們由于業務壓力，業務壓力沒有搞成；今年我們總算是有一點啟動，已經和appStudio的同學在共建，基于appStudio基礎之上把我們的dawn、云查詢做打通，做云端集成化、一站式的研發體驗。

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

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

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

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

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

有句話叫：飽暖思淫欲，不太恰當，姑且一比。在前端縱深領域的深耕，讓我們成為了「緊缺資源」，隨著工具的完善，前端們也更希望利用技術為業務賦能。如何賦能？擋在我們面前的是「意識」。在營銷中，認知、需求、品牌、品類、價格五個要素中，「認知」最為重要。比如阿里是做電商的、騰訊是做社交的、百度是做搜索的，bat在自己主營業務范疇不斷布局，構建了龐大的生態，做過很多嘗試，但看起來最終還是圍繞本身的基因做生態投資成功率要高一些。那我們想要業務賦能，瓶頸就在于「你個切頁面」也要賦能嗎？好好做好體驗、提效不好嗎？我認為「體驗、提效」這是前端最核心的能力，也是畢生都努力要實現的目標，坦白講我們沒法馬上解決資源瓶頸問題，畢竟現在畢業生都在應聘算法、ai、人工智能；我們也沒辦法搞一輪體驗提升計劃；這是個很漫長的過程。但如果我們能以業務的角度出發，去發現問題進而輔助以技術手段解決，并沉淀平臺，應對未來千變萬化的需求，可能更為實際一些。做為團隊的TL，除了在專業上給與同學「|」型的能力縱深，也更希望帶著團隊同學獲得更多業務體感。離開業務談技術、談中臺都是空中樓閣；離開業務談前端，注定只能是重復造輪子，而這種低水平的重復正在發生，且可能會持續很久。

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

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

官網&營銷：主要包含獲客、激活、轉換、留存幾個節點，構建高效的「人」、「貨」、「場」。很長一段時間里，阿里云的內容維護、營銷大促都是基于集團CMS來的。傳統大促會場、卡片的方式，前端挖坑后運營編輯內容，而阿里云的「商品」跟淘系有著比較大的差別，另外我們也沒有招商、選品的體系，導致這種簡單人肉運行的大促方式存在很多弊端，比如不高效、不復用、不能做個性化、數據流程監控力度不夠精細等。此外「投放」能力的建設還不夠，沒有辦法做到精細化的人群做精準的營銷內容投放。為了解決這些問題，去年開始，由前端團隊和pd一起推進完善的營銷體系建設：

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

商業化商品配置：上面提到「營銷商品」時提到「基礎商品」。目前阿里云基礎商品主要分為：「公有云商品」和「技術輸出型」。過去很長一段時間我們偏公有云的能力建設，今年年初才開始逐步融入專有云體系。在商業化系統中，我們的小二需要配置售賣規則、價格，需要定義商品模型；同時復雜的規格之間的約束，異常復雜。如何提高商業化的輸入和輸出的強體驗，我們還有很長的路要走。結合今年的專有云項目，從模板的方式出發，將一類產品做個聚合，簡化商品模型配置的步驟，大大提高了配置效率，提高體驗。

銷售&合作伙伴：15年剛開始組建團隊(這里指的都是前端團隊，不是業務團隊)，15年-18.3月大部門的核心kpi是營收、是首購用戶數，主打的是中長尾客戶，獲得了非常高速的市場增長。后來團隊cover范圍不斷擴大，也負責銷售&合作伙伴體系，圍繞著「市場營銷」、「商機培育」、「商機轉化」、「合同履約」構建了我們自己的銷售crm系統。toC的業務通常比較好理解，畢竟我們也是c的一員。這段toB的經歷，結合業務一號位的培訓班，讓了解到銷售系統的核心，除了工具，最想要的是解決方案，是產品能力的豐富。

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

從這個流程大圖中，各個分支最后都需要依賴「售賣能力」，這個售賣能力

• 表現在營銷中是「彈窗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（首席頁面仔啊）

ps：阿里云智能業務中臺&阿里通信招P6-P8前端，歡迎來撩。base可北京可杭州，杭州工位在美麗的西溪園區哦。旁邊挨著的都是UED妹子&測試妹子。xiaoming.dxm@alibaba-inc.com

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

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

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