李成熙：前端如何突破技術與業務的瓶頸

作者：李成熙，Shopee 金融商家前端團隊負責人。2014 年度畢業加入騰訊 AlloyTeam，先後負責過 QQ 群、花樣直播、騰訊文檔等項目。2018 年加入騰訊雲雲開發團隊。2019 年加入 Shopee 金融前端團隊任一線前端 Leader。專注于性能優化、工程化和小程式服務。

微信轉載前，請聯系公衆号/作者，未經許可不能轉載!

上次寫總結文章，是來 Shopee 剛好半年後，那時剛剛适應從個人貢獻者到技術架構師和管理者的身份轉變，有一些感悟與心得，拿出來與大家分享。又一年過去了，來 Shopee 已經一年半，團隊從剛開始時的 4 個人，到現在 18 人，公司股價，也從當初的 20 美金，到 180 美金。很有幸，公司在進步，我也在進步。

今天主要想分享三個作為前端，可能經曆的瓶頸，然後講講我為了突破這些瓶頸，所做的一些思考與努力。這三個突破，分别是

• 從個人貢獻者到技術架構師與管理者轉變的突破
• 從帶領單項技術到帶領多項技術的突破
• 從帶技術到帶業務的突破

瓶頸一：從個人貢獻者到技術架構師與管理者轉變的突破

其實這個可以從架構能力與管理能力兩個層面講。咱們先來講一下架構能力。

架構師

所謂架構能力，簡單地說就是将不同的子產品、元件、系統組裝起來，關聯發揮作用，解決業務或技術需求的一個過程，網上可能有更詳盡的解釋，大家可以自行去了解。開發者在個人貢獻者階段，更多隻是接受架構師指派的任務，完成自己一個小子產品的設計與代碼。而在架構師的階段，要擔負起的責任與工作則更多，而且既要兼顧全局，有時也要 Review 細節的落實，有時候是又當建築設計師，又當工地監工。

作為架構師，首先要對需求的把握非常清晰，一個是需求要落實的功能點，另一個是要考慮一些特性，譬如性能，未來的擴充性等等。以最近我們計劃要做的一個産品的官網為例，這個官網比較核心的特性，一個是釋出新聞、一些推廣活動還有常見問答，另一個是可以提供這些内容的相關搜尋，還有對個别商家做一些排行榜。

由于背景的人力不足，我們是計劃由前端完成大部分的前端與背景開發工作，這裡就需要由一位既懂前端，又懂背景的架構師去設計把關這裡的架構（當然分開架構也可以）。這裡你可能會有疑問，為什麼前端的架構師，有能力在這個需求裡，對前背景做架構設計呢？前端的同僚是何德何能可以承擔這裡的前背景開發呢？這裡就涉及到技術管理的梯隊建設與才能儲備，咱們講管理的時候再詳聊。

基于該需求的特性，我們在做設計之前，還需要收集一下這個站點未來可能的通路量（資料），這些資料對我們的技術選型非常關鍵！沒錯，我們點出了架構第一個重要的環節，技術選型。據了解，該站點每天通路量，每秒的并發都不大，基本不需要上到一些應對高并發的手段。另外，由于要做内容的全文搜尋，如果通過資料庫的全文檢索，盡管使用量不大，但随着内容越來越多（營運人員更新内容的頻率還是很高的），查詢性能會越來越慢。而且我們的資料庫暫時跟一些核心交易資料放在同一個資料庫叢集裡，這種耗時操作可能會加大對資料庫叢集的壓力，是以我們可能需要用到

ElasticSearch

幫我們做切詞與搜尋。而對商家資料做排行榜，這個由于涉及到核心資料，我計劃是讓背景的微服務出一個

API

，再由咱們

Node.js

(由于是前端來實作背景能力，基于熟悉度的考量，用

Node.js

對于前端來說，開發與維護都相當友善) 服務層去調用。

在技術選型的基礎上，架構師平時積累的一些經驗、方法論、名額關注面，在架構設計中，也起到比較重要的作用。這裡以團隊做的熱更新服務、配置中心、營運搭建頁面這幾個平台為例。剛組建團隊的時候，我們亟需熱更新平台來給

React Native

提供動态更新的能力。這裡當時是采用了

MySQL + Redis + Node.js + Serverless Function(做代碼差分)

的架構。

熱更新平台的架構

有了熱更新服務的經驗，後面在做配置中心和營運搭建頁面的時候，也從中吸取了經驗，用了類似的架構做資料的存儲與緩存。但随着業務的發展，我們發現為了讓系統的可用性更高、性能更好，在一些場景裡，對資料量比較大的讀取，經常會将資料放到記憶體裡（Redis 讀取大資料也會有瓶頸）；另外在做差分的時候，為了保證準确性，設計了一個任務隊列，保證任務不會被重複運作，也安排了一些失敗重試、人工處理等的機制。在設計任務隊列的時候，我們有考慮過引入

Kafka

這類中間件，但實質上用

MySQL

也能滿足到訴求，那考慮到可移植性，是以咱們直接就用

MySQL

頂上。上面講的這些例子，都是在業務發展過程中，架構的演進，并且在這種疊代的過程中，自己的架構經驗與方法論也不斷豐富，日後遇到類似的問題，就像砌積木那樣子，搬出曾經用過、思考過、驗證過的種種方案，建構成心目中的模樣。你可能會說，架構師的工作難度蠻大的，時刻會遇到自己無知的領域，比如自己之前沒有用過的一些中間件，在真正面臨需求的時候，怎麼會想得到？這裡感覺并沒有捷徑，隻有在日常工作中不斷涉獵，打開自己的眼界，才能在不斷變化的需求世界裡更為從容。

小結一下，成為架構師需要做到的事情：

1. 根據需求特性、名額資料、團隊熟悉度，做好技術選型。
2. 根據經驗、方法論、名額資料，不斷豐富與完善自己的架構方案與套件
3. 不斷學習，沒有捷徑

管理者

技術管理這個話題，可能講幾天幾夜也講不完，這裡我隻摘取我認為最為重要與關鍵的一些做法與理念。在理念上，我認為要讓大家高效工作、快樂工作，在實施上，要想盡辦法給團隊、給成員賦能。

從業界的趨勢來看，許多業務、技術領域也已經走到了深水區、國際比較前沿的階段，不是簡單的拼人力、拼時間就可以将事情做對、做漂亮的，讓大家抱着快樂的心情，發揮自己的創造力地去做事情，比讓大家拼盡一切時間，還時不時在工位摸魚，更能可能将事情做好。畢竟我們是将要在國際舞台上跟巨頭拼刺刀的公司，在找對方向後，跟時間賽跑是沒問題的，但在找對方向之前盲目地虛耗大家的精力與創造力，可能會引發一将無能，累死三軍的局面。

高效工作，可以從個人與團隊兩個角度進行賦能。

個人層面上，本質就是希望個人的能力不斷提升，大家能夠找到自己發展的目标，技能上做到一專多長，并且最終達成為一位自帶“體系”的技術人。譬如今年我們團隊來了一位

React Native

的大牛，自己的曾經的創業項目也是整體用

React Native

搭建

iOS

和

Android

的

APP

。但

React Native

，有一個很重要的特性就是熱更新，在他之前的項目裡還沒用到過，更别說自研了。來我們團隊後，有契機讓他參與熱更新項目的研發，并且也讓他多了解用戶端實作這套體系的一些基本的邏輯。後續如果公司有新的業務有需要到

React Native

，那這位同僚就可以作為自帶“體系”的架構師，去幫忙搭建業務的架構，促進業務的發展。

這是自帶體系的一位同學，在公司做熱更新平台的技術分享

團隊層面上，做好子產品劃分、流程優化、技術規劃與梯隊建設。

所謂子產品劃分，就是大家在相對穩定的子產品中工作，當你比較熟悉業務邏輯的話，工作都相對容易。當然對相似工作内容産生倦怠人皆有之，這個又可以開另一個專題闡述了。早期我在這裡也踩過一些坑，也是由于團隊早期的業務比較緊，盡管同僚還是會盡量做他們熟悉的子產品，奈何不同的版本，不同子產品的業務壓力大小不盡相同，會經常抽調同僚去負責全新的子產品，這樣其實對工作的效率與品質都是不利的，花的時間長，産生的 BUG 也多。是以後續也盡量讓人員相對更加強定，即使後續某個子產品非常忙，也盡量由負責該子產品的同僚主導業務開發的工作，支援的同僚需要在良好的指引下（文檔一定要完備）開展工作。

流程優化，即使減少工作中的流程對研發人員帶來的桎梏。工作流程有許多，建立新項目的流程，如 Git 工作流、任務工作單管理流程等等。如何優化流程我認為主要是識别反人性的流程，然後用工具優化之。這裡以團隊中的任務工作單流程優化為例，在 Shopee，研發團隊有采用一款任務工作建單平台做研發流程的管理的，大家都會在這個建單平台上面記錄工作量以及扭轉狀态。團隊剛開始的時候人比較少，誰忙誰閑一目了然，但随着團隊人員不斷增加，單純通過肉眼、心算去看看大家的忙閑程度，配置設定工作就變得極具挑戰性了，在沒有工作的幫助下，管理半徑就會限制在 5 - 8 個人左右，而且為了配置設定工作會把自己忙死——要做大量的手動統計工作。于是為了提供管理的效率，我決定寫了一個腳本，幫我通過建單平台的開放 API，将團隊内成員的工作量，全部都拉下來放到 Excel 裡被自動将工作量總量統計出來。這樣配置設定工作，隻需要跑一個腳本，就可以輕松統計出每個人的已經排的工作量。當然，如果能統計出甘特圖是最完美的，但受限于個别資料團隊沒有要求填（比如工作開始時間），是以就無法畫出來。

這位同僚本周已經排滿了，再排就超負荷了

除此以外，由于項目經理一些研發統計的需要，對每個同僚建任務單的要求、填字段的數量都越來越多。将心比己，即使是我本人作為 member，都可能會疏忽未能填寫完成準确。這些措施對管理上可能會更加友善，但對每個研發來說都會增加負擔與困擾。于是我們也計劃做一些工具與平台，一方面友善管理者做統計，另一方面也減少研發人員在一些行政、流程上的事情浪費過多的時間。

技術規劃，主要就是引領整個團隊的技術方向，并努力将之落地，這個是技術管理者展現價值的非常重要的環節。因為子產品劃分、流程優化，有做導師帶過小項目之後，都能得心應手，但技術規劃，怎麼順應着業務的發展變化，提前做一些技術的儲備與布局，怎麼将團隊的技術水準帶到業界一流水準，這個是當上技術管理者之後才能得到的體會。

所謂的規劃，不能是單點的突破，而是需要多點，并且點連成線面；不能隻着重于一個個工具與平台的建設，而更要關注這些工具與平台如何有機地結合在一起，協同發揮作用，形成體系。當然，也需要這些技術與時俱進，在技術的規劃前路上，也逐漸識别并摘除一些技術債務。

Shopee金融商家前端團隊的體系規劃

Shopee金融商家前端團隊的一些體系落地的裡程碑與展望

用表格記錄每個業務子產品的技術債務與問題，并安排清理

梯隊建設也是我認為非常重要的一環。能否規劃與組建你的團隊，是技術管理者與架構師非常重要的差別之一。梯隊建設為什麼重要，那是因為良好的梯隊建設，一方面能讓你的團隊人員更穩固，畢竟大家都有成長的訴求，無論是當技術管理還是架構師，都或多或少需要帶人完成更具挑戰性的項目，單打獨鬥能成事者寥寥無幾。今年年中的時候，大批校招生準備進場。當時分析自己的團隊，有 5 - 6 個進階或者準進階工程師了，這些進階的工程師工作經驗都比較豐富了，但一直沒有帶人的機會，同時也由于業務比較繁忙，于是我就趁機會要了足夠數量的畢業生，讓他們帶帶人。我是希望通過手把手帶人，可以更好地激發他們的責任心，也可以讓畢業生跟着他們去做一些技術規劃裡的項目，讓這些進階工程師也多鍛煉架構與管理能力。雖然早期難免會有陣痛，比如畢業生對流程不熟悉，研發品質可能會有下降，但經過三個月的試用期後，畢業生的工作都步入正規，有充足人力的情況下，許多的技術規劃落地都比較順利。

其次，梯隊建設的好壞，能決定你之前的技術規劃能否順利落地。除了前面提到的不同職級與經驗的人的比例要均衡，還需要在各個技術方向有技術儲備，最好是有技術領頭人，甚至能有技術小組，畢竟孤身一人去探索某個技術方案還是挺孤獨寂寞的，也沒有人一起做技術讨論。另外有這樣的一個技術小組，也可以有備份人。在團隊中，因應着定下的技術規劃，基本上每個體系的建設都會成立一個技術小組，這些人可能在公司組織上并不是同一個組，但隻要他們對這塊感興趣，或者在這塊有建樹，就可以參與到這塊的建設中。比如在 Web 體系建設小組裡面，有三位同僚，這塊需要負責的項目比較多，包括 Web 釋出的自動化、精細化，Web 元件建設，Figma 元件生成自動化，同構渲染研究等都歸屬到這裡，每個人都有自己主攻的方向，但每一個時期側重點可能有不同，有可能會有有幾個人共同參與到某一個項目的建設當中，快速将該項目先做成。

我在跟Web體系建的同僚讨論技術方案

高效工作 如果落實得好，快樂工作其實也就達成一半以上了，因為高效工作可以讓工作效率提高，加班減少，也能讓大家有成長的快感，再加之以打造良好的技術氛圍（技術分享、外出參與技術會議、内部開放的技術讨論），相信員工的工作滿意度會相對較高。

從Facebook回國的前端大神，給我們徒手白闆講解端到端加密

小結一下，成為好的管理者，需要通過賦能做到：

1. 高效工作

• 子產品劃分，讓職責明确，業務熟練
• 流程優化，減少行政工作，提高代碼時間
• 技術規劃，指明方向，甩掉債務，提升個人技能與團隊效益
• 梯隊建設，儲備技術與落地規劃

• 快樂工作
• • 高效工作是前提
  • 打造良好的技術氛圍

  瓶頸二：從帶領單項技術到帶領多項技術的突破

  随着職級的提升，要跟跨團隊的技術合作、甚至帶跨技術的項目、同時帶其它的技術組的情況會越來越多。如果倒推幾年，前端要進入背景、用戶端的領域，難度還是比較大的，這個是整個業界都存在的問題。但随着一些重要的技術的誕生與成熟，比如 Node.js，React Native, Electron 進入前端人的視野，前端有更多的機會可以參與到這些。是以從大局上、宏觀上講，我們要多支援這些技術的成長，無論是給這些開源項目貢獻源碼、布道、貢獻最佳實踐，最終都能讓我們自己受益。是以我在團隊裡也比較鼓勵大家貢獻開源項目，或者通過造開源項目的周邊小輪子練練手。

  但從自己團隊的業務與技術發展，這個微觀的層面來看更着重看的是自己團隊在某塊跨領域技術的知識儲備、人才儲備與項目曆練。舉個例子，如果前端要能夠承接個别的中背景業務，必需要團隊裡面的 Node.js 基建設施比較完善，并且要有相關的人才能夠 Hold 得住，否則哪裡報了 Node.js 的錯誤，哪裡産生的性能瓶頸，哪裡出現疑難雜症，沒有人有思路解決，這就很可能會阻塞到業務的進展。

  我個人的建議是，首先要讓基建設施完備，譬如将 Node.js 部署到 K8S 的設施搭建起來，包括程序管理器、上報埋點的工具庫、Node.js 的基礎 Docker 鏡像等等。基建完備後，我們先用一些技術項目練手，尤其是在許多跟用戶端一起合作的項目裡，由于有前端能寫 Node.js 的緣故，一些大前端的公共平台，比如熱更新釋出平台、配置中心等的一些項目，都可以由前端來做主要推手，通過這些項目來積累一些高并發、高可用的背景開發與運維經驗，進而擷取背景開發的經驗。如果不想如此的激進，也可以從一些偏管理背景的項目開始，這些老闆們是比較放心讓 Node.js 來實作的。當擁有了基礎的 Node.js 開發與運維經驗後，可以開始在業務中做一些嘗試，尤其是那些中台的接口轉發項目、或者是同構渲染提升性能的項目。隻有跨越出來，能做一些使用者側業務的 Node.js 服務，這樣才能更進一步通過解決使用者側的服務挑戰來提升團隊的實力。我們當時是選擇了一個非常适合前端 Node.js 來實作的服務，就是使用者購買商品後的訂單詳情頁。這個頁面，産品要求的動态化非常高，不同産品的字段不盡相同，而且可能時不時調整順序或者添加字段。而且背景提供的定的接口，又不太好表現一些字段的分類、字段的排序、字段展示的格式等。于是我們就提出，用 Node.js 做一個中間服務，将這些商品的詳情字段全部做成可配置化，并在 React Native 側做了一個基礎的展示引擎，基于背景傳回的字段動态渲染。

  

  不同商品的字段的交易詳情頁字段不盡相同

  

  将交易詳情字段全數在Node.js服務中實作可配置化

  有了不少的技術項目還有這次業務項目的實踐成功，大大增強了前端的信心，等到後續背景由于人力原因無法投入太多精力到産品官網的開發，前端就順其自然地接受了這個挑戰，會去做全站的前背景開發任務，在業務中更深層次地使用 Node.js。

  做一下小結，想突破目前單一技術的管理，如果以中背景為例的話，可以嘗試走以下的步驟：

  1. 搭好基礎設施，以小項目練手
  2. 在大前端中主導一些相關的背景項目建設，赢得高可用、高性能的經驗
  3. 切入中台業務，嘗試背景服務的中間層
  4. 往“後”拓展，可嘗試非核心業務的全棧落地

  瓶頸三：從帶技術到帶業務的突破

  前端，乃至大部分的研發，被作為工具人，長久隻是需求的實作機器，能真正突破從做技術到帶業務的人少之又少。這個突破有兩個層次，一個是成為這個業務子產品的整體技術負責人，另一個層次是直接成為這個業務的總負責人。遺憾的是，本人都未能達到這些層次，目前隻是粗略地談一下我自己做的一些嘗試，而且主要是第一個層次的嘗試。

  一個研發是不是關注業務，其實隻要你問一下他，是否知道這個産品面向的使用者，使用者規模、活躍使用者有多少，GMV 有多少等等的一些關鍵業務資料，如果他能答出一些，而不是完全不知道，那證明這位研發還是比較關心業務的。有這樣良好的關心業務資料的習慣，相信更進一步，讓這位研發不僅隻了解自己子產品的業務邏輯，可以将背景、用戶端跟某個子產品相關的業務邏輯都了解一遍還是比較容易的。并且老闆、産品、測試人員來問的時候，都能比較清楚地做出解釋，那這位研發熟悉業務的名聲就已經遠播了。

  但是，有的時候盡管你可能對這些業務有所了解，但由于在前端這個崗位上，天然可能就比背景有一定的劣勢——畢竟業務的最主要的流程是在背景實施的。這些對于金融、電商的行業尤其如此，可能相比之下，社交、内容、工具等平台，前端的話語權可能反倒更大一些。加上如果你做了大量的技術項目，盡管你對業務其實也了解，也可能會給别人留下過于關注技術，而忽略業務的印象——畢竟每次項目會上，需要解決的背景的問題，比前端和用戶端高出一大截，我們也不太好去插話。是以，在重視技術建設的同時，也可以多對業務的流程提出一些優化，比如後續我就吸取一些經驗教訓，希望在一些商品上新的流程上做一些簡化，減少每次上新投入的人力，使整個項目組的人力規劃可以向其它更重要的事情上傾斜。

  此外，我們也可以嘗試針對業務當下或者未來的訴求做一些産品的孵化。比如作為金融電商平台，比較容易想到的就是一些正常營運頁面的搭建工具，畢竟前端在産品做使用者增長這塊，還是可以發揮比較大的作用。于是斷斷續續，我們團隊就搭建了一個可以跨多個 APP 運作的營運頁面搭建工具。在做這些項目的孵化過程中，并不是一帆風順的，比方說這些産品要從政策、設計到落地都需要團隊的人從頭做起，推動營運人員的使用也并非一帆風順，也成就也有挫敗。但經過這些曆練之後，讓自己對業務、産品的把握也會有另一番的見解。雖然目前的這些努力未有很明顯的成效，但團隊人員在産品設計、打磨、落地方面的能力得到了儲備，正所謂養兵千日，用在一時，相信未來可能将會有這些産品、人員發揮的地方。

  

  可拖拽式營運頁面搭建工具

  小結一下，從帶技術到帶業務的一些努力：

  1. 關注業務，從關注業務的資料、邏輯開始，并且多端的邏輯都需要熟悉
  2. 技術項目與業務項目都要兩手抓，并且需要有自己團隊主推落地的一些核心業務需求與優化
  3. 嘗試孵化與業務相關或者與公司發展戰略一緻的産品

  總結

  來 Shopee 一年半，變化翻天覆地，從來不敢想象自己會有機會去突破這些職業的界限，或者摸到這些職業界限的天花闆。希望這些粗淺的經驗能夠對後來都有些啟發，也希望一些同行、前輩可以多多指點，不吝賜教。同時感謝我團隊的同僚與老闆，這一年多以來對我不遺餘力的支援！

  最後

  如果你覺得這篇内容對你挺有啟發，我想邀請你幫我三個小忙：
  1. 點個「在看」，讓更多的人也能看到這篇内容（喜歡不點在看，都是耍流氓 -_-）
  2. 歡迎加我微信「qianyu443033099」拉你進技術群，長期交流學習...
  3. 關注公衆号「前端下午茶」，持續為你推送精選好文，也可以加我為好友，随時聊騷。

  

  

  點個在看支援我吧，轉發就更好了