前言
今年是我畢業的第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等等。Dawn連接配接：
https://github.com/alibaba/dawn講完工程化，其實應該講講元件化，這是個無法回避的問題，但這對我們來說也是個艱難的過程。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妹子&測試妹子。[email protected]