我在阿里雲作前端

前言

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

1.0版本-工具&團隊

今年是我來阿里雲的第五個年頭了，從沒有想過會在一個公司呆的如此之久，更沒想過我能在一個崗位上沉澱四、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

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。