前言
今年是我畢業的第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連線：github.com/alibaba/daw…
講完工程化，其實應該講講元件化，這是個無法迴避的問題，但這對我們來說也是個艱難的過程。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
本文作者：阿里雲高階前端技術專家 城池
原文連結：https://yq.aliyun.com/articles/695361?utm_content=g_1000049154