前端如何突破技術(shù)與業(yè)務(wù)的瓶頸 — Shopee一年半記

作者：李成熙，Shopee 金融商家前端團(tuán)隊(duì)負(fù)責(zé)人。2014 年度畢業(yè)加入騰訊 AlloyTeam，先后負(fù)責(zé)過 QQ 群、花樣直播、騰訊文檔等項(xiàng)目。2018 年加入騰訊云云開發(fā)團(tuán)隊(duì)。2019 年加入 Shopee 金融前端團(tuán)隊(duì)任一線前端 Leader。專注于性能優(yōu)化、工程化和小程序服務(wù)。

微信轉(zhuǎn)載前，請(qǐng)聯(lián)系公眾號(hào)/作者，未經(jīng)許可不能轉(zhuǎn)載!

上次寫總結(jié)文章，是來 Shopee 剛好半年后，那時(shí)剛剛適應(yīng)從個(gè)人貢獻(xiàn)者到技術(shù)架構(gòu)師和管理者的身份轉(zhuǎn)變，有一些感悟與心得，拿出來與大家分享。又一年過去了，來 Shopee 已經(jīng)一年半，團(tuán)隊(duì)從剛開始時(shí)的 4 個(gè)人，到現(xiàn)在 18 人，公司股價(jià)，也從當(dāng)初的 20 美金，到 180 美金。很有幸，公司在進(jìn)步，我也在進(jìn)步。

【半年前寫的文章】：互聯(lián)網(wǎng)技術(shù)人在快速發(fā)展團(tuán)隊(duì)的獨(dú)當(dāng)一面之道——Shopee半年記

今天主要想分享三個(gè)作為前端，可能經(jīng)歷的瓶頸，然后講講我為了突破這些瓶頸，所做的一些思考與努力。這三個(gè)突破，分別是

• 從個(gè)人貢獻(xiàn)者到技術(shù)架構(gòu)師與管理者轉(zhuǎn)變的突破
• 從帶領(lǐng)單項(xiàng)技術(shù)到帶領(lǐng)多項(xiàng)技術(shù)的突破
• 從帶技術(shù)到帶業(yè)務(wù)的突破

瓶頸一：從個(gè)人貢獻(xiàn)者到技術(shù)架構(gòu)師與管理者轉(zhuǎn)變的突破

其實(shí)這個(gè)可以從架構(gòu)能力與管理能力兩個(gè)層面講。咱們先來講一下架構(gòu)能力。

架構(gòu)師

所謂架構(gòu)能力，簡(jiǎn)單地說就是將不同的模塊、組件、系統(tǒng)組裝起來，聯(lián)動(dòng)發(fā)揮作用，解決業(yè)務(wù)或技術(shù)需求的一個(gè)過程，網(wǎng)上可能有更詳盡的解釋，大家可以自行去了解。開發(fā)者在個(gè)人貢獻(xiàn)者階段，更多只是接受架構(gòu)師指派的任務(wù)，完成自己一個(gè)小模塊的設(shè)計(jì)與代碼。而在架構(gòu)師的階段，要擔(dān)負(fù)起的責(zé)任與工作則更多，而且既要兼顧全局，有時(shí)也要 Review 細(xì)節(jié)的落實(shí)，有時(shí)候是又當(dāng)建筑設(shè)計(jì)師，又當(dāng)工地監(jiān)工。

作為架構(gòu)師，首先要對(duì)需求的把握非常清晰，一個(gè)是需求要落實(shí)的功能點(diǎn)，另一個(gè)是要考慮一些特性，譬如性能，未來的擴(kuò)展性等等。以最近我們計(jì)劃要做的一個(gè)產(chǎn)品的官網(wǎng)為例，這個(gè)官網(wǎng)比較核心的特性，一個(gè)是發(fā)布新聞、一些推廣活動(dòng)還有常見問答，另一個(gè)是可以提供這些內(nèi)容的相關(guān)搜索，還有對(duì)個(gè)別商家做一些排行榜。

由于后臺(tái)的人力不足，我們是計(jì)劃由前端完成大部分的前端與后臺(tái)開發(fā)工作，這里就需要由一位既懂前端，又懂后臺(tái)的架構(gòu)師去設(shè)計(jì)把關(guān)這里的架構(gòu)（當(dāng)然分開架構(gòu)也可以）。這里你可能會(huì)有疑問，為什么前端的架構(gòu)師，有能力在這個(gè)需求里，對(duì)前后臺(tái)做架構(gòu)設(shè)計(jì)呢？前端的同事是何德何能可以承擔(dān)這里的前后臺(tái)開發(fā)呢？這里就涉及到技術(shù)管理的梯隊(duì)建設(shè)與才能儲(chǔ)備，咱們講管理的時(shí)候再詳聊。

基于該需求的特性，我們?cè)谧鲈O(shè)計(jì)之前，還需要收集一下這個(gè)站點(diǎn)未來可能的訪問量（數(shù)據(jù)），這些數(shù)據(jù)對(duì)我們的技術(shù)選型非常關(guān)鍵！沒錯(cuò)，我們點(diǎn)出了架構(gòu)第一個(gè)重要的環(huán)節(jié)，技術(shù)選型。據(jù)了解，該站點(diǎn)每天訪問量，每秒的并發(fā)都不大，基本不需要上到一些應(yīng)對(duì)高并發(fā)的手段。另外，由于要做內(nèi)容的全文搜索，如果通過數(shù)據(jù)庫的全文檢索，盡管使用量不大，但隨著內(nèi)容越來越多（運(yùn)營(yíng)人員更新內(nèi)容的頻率還是很高的），查詢性能會(huì)越來越慢。而且我們的數(shù)據(jù)庫暫時(shí)跟一些核心交易數(shù)據(jù)放在同一個(gè)數(shù)據(jù)庫集群里，這種耗時(shí)操作可能會(huì)加大對(duì)數(shù)據(jù)庫集群的壓力，因此我們可能需要用到ElasticSearch幫我們做切詞與搜索。而對(duì)商家數(shù)據(jù)做排行榜，這個(gè)由于涉及到核心數(shù)據(jù)，我計(jì)劃是讓后臺(tái)的微服務(wù)出一個(gè) API，再由咱們 Node.js(由于是前端來實(shí)現(xiàn)后臺(tái)能力，基于熟悉度的考量，用Node.js對(duì)于前端來說，開發(fā)與維護(hù)都相當(dāng)方便) 服務(wù)層去調(diào)用。

在技術(shù)選型的基礎(chǔ)上，架構(gòu)師平時(shí)積累的一些經(jīng)驗(yàn)、方法論、指標(biāo)關(guān)注面，在架構(gòu)設(shè)計(jì)中，也起到比較重要的作用。這里以團(tuán)隊(duì)做的熱更新服務(wù)、配置中心、運(yùn)營(yíng)搭建頁面這幾個(gè)平臺(tái)為例。剛組建團(tuán)隊(duì)的時(shí)候，我們亟需熱更新平臺(tái)來給React Native提供動(dòng)態(tài)更新的能力。這里當(dāng)時(shí)是采用了MySQL + Redis + Node.js + Serverless Function(做代碼差分)的架構(gòu)。

有了熱更新服務(wù)的經(jīng)驗(yàn)，后面在做配置中心和運(yùn)營(yíng)搭建頁面的時(shí)候，也從中吸取了經(jīng)驗(yàn)，用了類似的架構(gòu)做數(shù)據(jù)的存儲(chǔ)與緩存。但隨著業(yè)務(wù)的發(fā)展，我們發(fā)現(xiàn)為了讓系統(tǒng)的可用性更高、性能更好，在一些場(chǎng)景里，對(duì)數(shù)據(jù)量比較大的讀取，經(jīng)常會(huì)將數(shù)據(jù)放到內(nèi)存里（Redis 讀取大數(shù)據(jù)也會(huì)有瓶頸）；另外在做差分的時(shí)候，為了保證準(zhǔn)確性，設(shè)計(jì)了一個(gè)任務(wù)隊(duì)列，保證任務(wù)不會(huì)被重復(fù)運(yùn)行，也安排了一些失敗重試、人工處理等的機(jī)制。在設(shè)計(jì)任務(wù)隊(duì)列的時(shí)候，我們有考慮過引入 Kafka 這類中間件，但實(shí)質(zhì)上用MySQL也能滿足到訴求，那考慮到可移植性，因此咱們直接就用MySQL頂上。上面講的這些例子，都是在業(yè)務(wù)發(fā)展過程中，架構(gòu)的演進(jìn)，并且在這種迭代的過程中，自己的架構(gòu)經(jīng)驗(yàn)與方法論也不斷豐富，日后遇到類似的問題，就像砌積木那樣子，搬出曾經(jīng)用過、思考過、驗(yàn)證過的種種方案，構(gòu)建成心目中的模樣。你可能會(huì)說，架構(gòu)師的工作難度蠻大的，時(shí)刻會(huì)遇到自己無知的領(lǐng)域，比如自己之前沒有用過的一些中間件，在真正面臨需求的時(shí)候，怎么會(huì)想得到？這里感覺并沒有捷徑，只有在日常工作中不斷涉獵，打開自己的眼界，才能在不斷變化的需求世界里更為從容。

小結(jié)一下，成為架構(gòu)師需要做到的事情：

1. 根據(jù)需求特性、指標(biāo)數(shù)據(jù)、團(tuán)隊(duì)熟悉度，做好技術(shù)選型。
2. 根據(jù)經(jīng)驗(yàn)、方法論、指標(biāo)數(shù)據(jù)，不斷豐富與完善自己的架構(gòu)方案與套件
3. 不斷學(xué)習(xí)，沒有捷徑

管理者

技術(shù)管理這個(gè)話題，可能講幾天幾夜也講不完，這里我只摘取我認(rèn)為最為重要與關(guān)鍵的一些做法與理念。在理念上，我認(rèn)為要讓大家高效工作、快樂工作，在實(shí)施上，要想盡辦法給團(tuán)隊(duì)、給成員賦能。

從業(yè)界的趨勢(shì)來看，許多業(yè)務(wù)、技術(shù)領(lǐng)域也已經(jīng)走到了深水區(qū)、國際比較前沿的階段，不是簡(jiǎn)單的拼人力、拼時(shí)間就可以將事情做對(duì)、做漂亮的，讓大家抱著快樂的心情，發(fā)揮自己的創(chuàng)造力地去做事情，比讓大家拼盡一切時(shí)間，還時(shí)不時(shí)在工位摸魚，更能可能將事情做好。畢竟我們是將要在國際舞臺(tái)上跟巨頭拼刺刀的公司，在找對(duì)方向后，跟時(shí)間賽跑是沒問題的，但在找對(duì)方向之前盲目地虛耗大家的精力與創(chuàng)造力，可能會(huì)引發(fā)一將無能，累死三軍的局面。

高效工作，可以從個(gè)人與團(tuán)隊(duì)兩個(gè)角度進(jìn)行賦能。

個(gè)人層面上，本質(zhì)就是希望個(gè)人的能力不斷提升，大家能夠找到自己發(fā)展的目標(biāo)，技能上做到一專多長(zhǎng)，并且最終達(dá)成為一位自帶“體系”的技術(shù)人。譬如今年我們團(tuán)隊(duì)來了一位 React Native 的大牛，自己的曾經(jīng)的創(chuàng)業(yè)項(xiàng)目也是整體用 React Native 搭建 iOS和 Android 的 APP。但 React Native，有一個(gè)很重要的特性就是熱更新，在他之前的項(xiàng)目里還沒用到過，更別說自研了。來我們團(tuán)隊(duì)后，有契機(jī)讓他參與熱更新項(xiàng)目的研發(fā)，并且也讓他多了解客戶端實(shí)現(xiàn)這套體系的一些基本的邏輯。后續(xù)如果公司有新的業(yè)務(wù)有需要到 React Native，那這位同事就可以作為自帶“體系”的架構(gòu)師，去幫忙搭建業(yè)務(wù)的架構(gòu)，促進(jìn)業(yè)務(wù)的發(fā)展。

團(tuán)隊(duì)層面上，做好模塊劃分、流程優(yōu)化、技術(shù)規(guī)劃與梯隊(duì)建設(shè)。

所謂模塊劃分，就是大家在相對(duì)穩(wěn)定的模塊中工作，當(dāng)你比較熟悉業(yè)務(wù)邏輯的話，工作都相對(duì)容易。當(dāng)然對(duì)相似工作內(nèi)容產(chǎn)生倦怠人皆有之，這個(gè)又可以開另一個(gè)專題闡述了。早期我在這里也踩過一些坑，也是由于團(tuán)隊(duì)早期的業(yè)務(wù)比較緊，盡管同事還是會(huì)盡量做他們熟悉的模塊，奈何不同的版本，不同模塊的業(yè)務(wù)壓力大小不盡相同，會(huì)經(jīng)常抽調(diào)同事去負(fù)責(zé)全新的模塊，這樣其實(shí)對(duì)工作的效率與質(zhì)量都是不利的，花的時(shí)間長(zhǎng)，產(chǎn)生的 BUG 也多。所以后續(xù)也盡量讓人員相對(duì)更加固定，即使后續(xù)某個(gè)模塊非常忙，也盡量由負(fù)責(zé)該模塊的同事主導(dǎo)業(yè)務(wù)開發(fā)的工作，支援的同事需要在良好的指引下（文檔一定要完備）開展工作。

流程優(yōu)化，即使減少工作中的流程對(duì)研發(fā)人員帶來的桎梏。工作流程有許多，創(chuàng)建新項(xiàng)目的流程，如 Git 工作流、任務(wù)工作單管理流程等等。如何優(yōu)化流程我認(rèn)為主要是識(shí)別反人性的流程，然后用工具優(yōu)化之。這里以團(tuán)隊(duì)中的任務(wù)工作單流程優(yōu)化為例，在 Shopee，研發(fā)團(tuán)隊(duì)有采用一款任務(wù)工作建單平臺(tái)做研發(fā)流程的管理的，大家都會(huì)在這個(gè)建單平臺(tái)上面記錄工作量以及扭轉(zhuǎn)狀態(tài)。團(tuán)隊(duì)剛開始的時(shí)候人比較少，誰忙誰閑一目了然，但隨著團(tuán)隊(duì)人員不斷增加，單純通過肉眼、心算去看看大家的忙閑程度，分配工作就變得極具挑戰(zhàn)性了，在沒有工作的幫助下，管理半徑就會(huì)限制在 5 - 8 個(gè)人左右，而且為了分配工作會(huì)把自己忙死——要做大量的手動(dòng)統(tǒng)計(jì)工作。于是為了提供管理的效率，我決定寫了一個(gè)腳本，幫我通過建單平臺(tái)的開放 API，將團(tuán)隊(duì)內(nèi)成員的工作量，全部都拉下來放到 Excel 里被自動(dòng)將工作量總量統(tǒng)計(jì)出來。這樣分配工作，只需要跑一個(gè)腳本，就可以輕松統(tǒng)計(jì)出每個(gè)人的已經(jīng)排的工作量。當(dāng)然，如果能統(tǒng)計(jì)出甘特圖是最完美的，但受限于個(gè)別數(shù)據(jù)團(tuán)隊(duì)沒有要求填（比如工作開始時(shí)間），因此就無法畫出來。

除此以外，由于項(xiàng)目經(jīng)理一些研發(fā)統(tǒng)計(jì)的需要，對(duì)每個(gè)同事建任務(wù)單的要求、填字段的數(shù)量都越來越多。將心比己，即使是我本人作為 member，都可能會(huì)疏忽未能填寫完成準(zhǔn)確。這些措施對(duì)管理上可能會(huì)更加方便，但對(duì)每個(gè)研發(fā)來說都會(huì)增加負(fù)擔(dān)與困擾。于是我們也計(jì)劃做一些工具與平臺(tái)，一方面方便管理者做統(tǒng)計(jì)，另一方面也減少研發(fā)人員在一些行政、流程上的事情浪費(fèi)過多的時(shí)間。

技術(shù)規(guī)劃，主要就是引領(lǐng)整個(gè)團(tuán)隊(duì)的技術(shù)方向，并努力將之落地，這個(gè)是技術(shù)管理者體現(xiàn)價(jià)值的非常重要的環(huán)節(jié)。因?yàn)槟K劃分、流程優(yōu)化，有做導(dǎo)師帶過小項(xiàng)目之后，都能得心應(yīng)手，但技術(shù)規(guī)劃，怎么順應(yīng)著業(yè)務(wù)的發(fā)展變化，提前做一些技術(shù)的儲(chǔ)備與布局，怎么將團(tuán)隊(duì)的技術(shù)水平帶到業(yè)界一流水平，這個(gè)是當(dāng)上技術(shù)管理者之后才能得到的體會(huì)。

所謂的規(guī)劃，不能是單點(diǎn)的突破，而是需要多點(diǎn)，并且點(diǎn)連成線面；不能只著重于一個(gè)個(gè)工具與平臺(tái)的建設(shè)，而更要關(guān)注這些工具與平臺(tái)如何有機(jī)地結(jié)合在一起，協(xié)同發(fā)揮作用，形成體系。當(dāng)然，也需要這些技術(shù)與時(shí)俱進(jìn)，在技術(shù)的規(guī)劃前路上，也逐步識(shí)別并摘除一些技術(shù)債務(wù)。

梯隊(duì)建設(shè)也是我認(rèn)為非常重要的一環(huán)。能否規(guī)劃與組建你的團(tuán)隊(duì)，是技術(shù)管理者與架構(gòu)師非常重要的區(qū)別之一。梯隊(duì)建設(shè)為什么重要，那是因?yàn)榱己玫奶蓐?duì)建設(shè)，一方面能讓你的團(tuán)隊(duì)人員更穩(wěn)固，畢竟大家都有成長(zhǎng)的訴求，無論是當(dāng)技術(shù)管理還是架構(gòu)師，都或多或少需要帶人完成更具挑戰(zhàn)性的項(xiàng)目，單打獨(dú)斗能成事者寥寥無幾。今年年中的時(shí)候，大批校招生準(zhǔn)備進(jìn)場(chǎng)。當(dāng)時(shí)分析自己的團(tuán)隊(duì)，有 5 - 6 個(gè)高級(jí)或者準(zhǔn)高級(jí)工程師了，這些高級(jí)的工程師工作經(jīng)驗(yàn)都比較豐富了，但一直沒有帶人的機(jī)會(huì)，同時(shí)也由于業(yè)務(wù)比較繁忙，于是我就趁機(jī)會(huì)要了足夠數(shù)量的畢業(yè)生，讓他們帶帶人。我是希望通過手把手帶人，可以更好地激發(fā)他們的責(zé)任心，也可以讓畢業(yè)生跟著他們?nèi)プ鲆恍┘夹g(shù)規(guī)劃里的項(xiàng)目，讓這些高級(jí)工程師也多鍛煉架構(gòu)與管理能力。雖然早期難免會(huì)有陣痛，比如畢業(yè)生對(duì)流程不熟悉，研發(fā)質(zhì)量可能會(huì)有下降，但經(jīng)過三個(gè)月的試用期后，畢業(yè)生的工作都步入正規(guī)，有充足人力的情況下，許多的技術(shù)規(guī)劃落地都比較順利。

其次，梯隊(duì)建設(shè)的好壞，能決定你之前的技術(shù)規(guī)劃能否順利落地。除了前面提到的不同職級(jí)與經(jīng)驗(yàn)的人的比例要均衡，還需要在各個(gè)技術(shù)方向有技術(shù)儲(chǔ)備，最好是有技術(shù)領(lǐng)頭人，甚至能有技術(shù)小組，畢竟孤身一人去探索某個(gè)技術(shù)方案還是挺孤獨(dú)寂寞的，也沒有人一起做技術(shù)討論。另外有這樣的一個(gè)技術(shù)小組，也可以有備份人。在團(tuán)隊(duì)中，因應(yīng)著定下的技術(shù)規(guī)劃，基本上每個(gè)體系的建設(shè)都會(huì)成立一個(gè)技術(shù)小組，這些人可能在公司組織上并不是同一個(gè)組，但只要他們對(duì)這塊感興趣，或者在這塊有建樹，就可以參與到這塊的建設(shè)中。比如在 Web 體系建設(shè)小組里面，有三位同事，這塊需要負(fù)責(zé)的項(xiàng)目比較多，包括 Web 發(fā)布的自動(dòng)化、精細(xì)化，Web 組件建設(shè)，F(xiàn)igma 組件生成自動(dòng)化，同構(gòu)渲染研究等都?xì)w屬到這里，每個(gè)人都有自己主攻的方向，但每一個(gè)時(shí)期側(cè)重點(diǎn)可能有不同，有可能會(huì)有有幾個(gè)人共同參與到某一個(gè)項(xiàng)目的建設(shè)當(dāng)中，快速將該項(xiàng)目先做成。

高效工作 如果落實(shí)得好，快樂工作其實(shí)也就達(dá)成一半以上了，因?yàn)楦咝Чぷ骺梢宰尮ぷ餍侍岣?，加班減少，也能讓大家有成長(zhǎng)的快感，再加之以打造良好的技術(shù)氛圍（技術(shù)分享、外出參與技術(shù)會(huì)議、內(nèi)部開放的技術(shù)討論），相信員工的工作滿意度會(huì)相對(duì)較高。

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

1. 高效工作

• 模塊劃分，讓職責(zé)明確，業(yè)務(wù)熟練
• 流程優(yōu)化，減少行政工作，提高代碼時(shí)間
• 技術(shù)規(guī)劃，指明方向，甩掉債務(wù)，提升個(gè)人技能與團(tuán)隊(duì)效益
• 梯隊(duì)建設(shè)，儲(chǔ)備技術(shù)與落地規(guī)劃

2. 快樂工作

• 高效工作是前提
• 打造良好的技術(shù)氛圍

瓶頸二：從帶領(lǐng)單項(xiàng)技術(shù)到帶領(lǐng)多項(xiàng)技術(shù)的突破

隨著職級(jí)的提升，要跟跨團(tuán)隊(duì)的技術(shù)合作、甚至帶跨技術(shù)的項(xiàng)目、同時(shí)帶其它的技術(shù)組的情況會(huì)越來越多。如果倒推幾年，前端要進(jìn)入后臺(tái)、客戶端的領(lǐng)域，難度還是比較大的，這個(gè)是整個(gè)業(yè)界都存在的問題。但隨著一些重要的技術(shù)的誕生與成熟，比如 Node.js，React Native, Electron 進(jìn)入前端人的視野，前端有更多的機(jī)會(huì)可以參與到這些。所以從大局上、宏觀上講，我們要多支持這些技術(shù)的成長(zhǎng)，無論是給這些開源項(xiàng)目貢獻(xiàn)源碼、布道、貢獻(xiàn)最佳實(shí)踐，最終都能讓我們自己受益。所以我在團(tuán)隊(duì)里也比較鼓勵(lì)大家貢獻(xiàn)開源項(xiàng)目，或者通過造開源項(xiàng)目的周邊小輪子練練手。

但從自己團(tuán)隊(duì)的業(yè)務(wù)與技術(shù)發(fā)展，這個(gè)微觀的層面來看更著重看的是自己團(tuán)隊(duì)在某塊跨領(lǐng)域技術(shù)的知識(shí)儲(chǔ)備、人才儲(chǔ)備與項(xiàng)目歷練。舉個(gè)例子，如果前端要能夠承接個(gè)別的中后臺(tái)業(yè)務(wù)，必需要團(tuán)隊(duì)里面的 Node.js 基建設(shè)施比較完善，并且要有相關(guān)的人才能夠 Hold 得住，否則哪里報(bào)了 Node.js 的錯(cuò)誤，哪里產(chǎn)生的性能瓶頸，哪里出現(xiàn)疑難雜癥，沒有人有思路解決，這就很可能會(huì)阻塞到業(yè)務(wù)的進(jìn)展。

我個(gè)人的建議是，首先要讓基建設(shè)施完備，譬如將 Node.js 部署到 K8S 的設(shè)施搭建起來，包括進(jìn)程管理器、上報(bào)埋點(diǎn)的工具庫、Node.js 的基礎(chǔ) Docker 鏡像等等?；ㄍ陚浜?，我們先用一些技術(shù)項(xiàng)目練手，尤其是在許多跟客戶端一起合作的項(xiàng)目里，由于有前端能寫 Node.js 的緣故，一些大前端的公共平臺(tái)，比如熱更新發(fā)布平臺(tái)、配置中心等的一些項(xiàng)目，都可以由前端來做主要推手，通過這些項(xiàng)目來積累一些高并發(fā)、高可用的后臺(tái)開發(fā)與運(yùn)維經(jīng)驗(yàn)，從而獲取后臺(tái)開發(fā)的經(jīng)驗(yàn)。如果不想如此的激進(jìn)，也可以從一些偏管理后臺(tái)的項(xiàng)目開始，這些老板們是比較放心讓 Node.js 來實(shí)現(xiàn)的。當(dāng)擁有了基礎(chǔ)的 Node.js 開發(fā)與運(yùn)維經(jīng)驗(yàn)后，可以開始在業(yè)務(wù)中做一些嘗試，尤其是那些中臺(tái)的接口轉(zhuǎn)發(fā)項(xiàng)目、或者是同構(gòu)渲染提升性能的項(xiàng)目。只有跨越出來，能做一些用戶側(cè)業(yè)務(wù)的 Node.js 服務(wù)，這樣才能更進(jìn)一步通過解決用戶側(cè)的服務(wù)挑戰(zhàn)來提升團(tuán)隊(duì)的實(shí)力。我們當(dāng)時(shí)是選擇了一個(gè)非常適合前端 Node.js 來實(shí)現(xiàn)的服務(wù)，就是用戶購買商品后的訂單詳情頁。這個(gè)頁面，產(chǎn)品要求的動(dòng)態(tài)化非常高，不同產(chǎn)品的字段不盡相同，而且可能時(shí)不時(shí)調(diào)整順序或者添加字段。而且后臺(tái)提供的定的接口，又不太好表現(xiàn)一些字段的分類、字段的排序、字段展示的格式等。于是我們就提出，用 Node.js 做一個(gè)中間服務(wù)，將這些商品的詳情字段全部做成可配置化，并在 React Native 側(cè)做了一個(gè)基礎(chǔ)的展示引擎，基于后臺(tái)返回的字段動(dòng)態(tài)渲染。

有了不少的技術(shù)項(xiàng)目還有這次業(yè)務(wù)項(xiàng)目的實(shí)踐成功，大大增強(qiáng)了前端的信心，等到后續(xù)后臺(tái)由于人力原因無法投入太多精力到產(chǎn)品官網(wǎng)的開發(fā)，前端就順其自然地接受了這個(gè)挑戰(zhàn)，會(huì)去做全站的前后臺(tái)開發(fā)任務(wù)，在業(yè)務(wù)中更深層次地使用 Node.js。

做一下小結(jié)，想突破目前單一技術(shù)的管理，如果以中后臺(tái)為例的話，可以嘗試走以下的步驟：

1. 搭好基礎(chǔ)設(shè)施，以小項(xiàng)目練手
2. 在大前端中主導(dǎo)一些相關(guān)的后臺(tái)項(xiàng)目建設(shè)，贏得高可用、高性能的經(jīng)驗(yàn)
3. 切入中臺(tái)業(yè)務(wù)，嘗試后臺(tái)服務(wù)的中間層
4. 往“后”拓展，可嘗試非核心業(yè)務(wù)的全棧落地

瓶頸三：從帶技術(shù)到帶業(yè)務(wù)的突破

前端，乃至大部分的研發(fā)，被作為工具人，長(zhǎng)久只是需求的實(shí)現(xiàn)機(jī)器，能真正突破從做技術(shù)到帶業(yè)務(wù)的人少之又少。這個(gè)突破有兩個(gè)層次，一個(gè)是成為這個(gè)業(yè)務(wù)模塊的整體技術(shù)負(fù)責(zé)人，另一個(gè)層次是直接成為這個(gè)業(yè)務(wù)的總負(fù)責(zé)人。遺憾的是，本人都未能達(dá)到這些層次，目前只是粗略地談一下我自己做的一些嘗試，而且主要是第一個(gè)層次的嘗試。

一個(gè)研發(fā)是不是關(guān)注業(yè)務(wù)，其實(shí)只要你問一下他，是否知道這個(gè)產(chǎn)品面向的用戶，用戶規(guī)模、活躍用戶有多少，GMV 有多少等等的一些關(guān)鍵業(yè)務(wù)數(shù)據(jù)，如果他能答出一些，而不是完全不知道，那證明這位研發(fā)還是比較關(guān)心業(yè)務(wù)的。有這樣良好的關(guān)心業(yè)務(wù)數(shù)據(jù)的習(xí)慣，相信更進(jìn)一步，讓這位研發(fā)不僅只了解自己模塊的業(yè)務(wù)邏輯，可以將后臺(tái)、客戶端跟某個(gè)模塊相關(guān)的業(yè)務(wù)邏輯都了解一遍還是比較容易的。并且老板、產(chǎn)品、測(cè)試人員來問的時(shí)候，都能比較清楚地做出解釋，那這位研發(fā)熟悉業(yè)務(wù)的名聲就已經(jīng)遠(yuǎn)播了。

但是，有的時(shí)候盡管你可能對(duì)這些業(yè)務(wù)有所了解，但由于在前端這個(gè)崗位上，天然可能就比后臺(tái)有一定的劣勢(shì)——畢竟業(yè)務(wù)的最主要的流程是在后臺(tái)實(shí)施的。這些對(duì)于金融、電商的行業(yè)尤其如此，可能相比之下，社交、內(nèi)容、工具等平臺(tái)，前端的話語權(quán)可能反倒更大一些。加上如果你做了大量的技術(shù)項(xiàng)目，盡管你對(duì)業(yè)務(wù)其實(shí)也了解，也可能會(huì)給別人留下過于關(guān)注技術(shù)，而忽略業(yè)務(wù)的印象——畢竟每次項(xiàng)目會(huì)上，需要解決的后臺(tái)的問題，比前端和客戶端高出一大截，我們也不太好去插話。因此，在重視技術(shù)建設(shè)的同時(shí)，也可以多對(duì)業(yè)務(wù)的流程提出一些優(yōu)化，比如后續(xù)我就吸取一些經(jīng)驗(yàn)教訓(xùn)，希望在一些商品上新的流程上做一些簡(jiǎn)化，減少每次上新投入的人力，使整個(gè)項(xiàng)目組的人力規(guī)劃可以向其它更重要的事情上傾斜。

此外，我們也可以嘗試針對(duì)業(yè)務(wù)當(dāng)下或者未來的訴求做一些產(chǎn)品的孵化。比如作為金融電商平臺(tái)，比較容易想到的就是一些常規(guī)運(yùn)營(yíng)頁面的搭建工具，畢竟前端在產(chǎn)品做用戶增長(zhǎng)這塊，還是可以發(fā)揮比較大的作用。于是斷斷續(xù)續(xù)，我們團(tuán)隊(duì)就搭建了一個(gè)可以跨多個(gè) APP 運(yùn)行的運(yùn)營(yíng)頁面搭建工具。在做這些項(xiàng)目的孵化過程中，并不是一帆風(fēng)順的，比方說這些產(chǎn)品要從策略、設(shè)計(jì)到落地都需要團(tuán)隊(duì)的人從頭做起，推動(dòng)運(yùn)營(yíng)人員的使用也并非一帆風(fēng)順，也成就也有挫敗。但經(jīng)過這些歷練之后，讓自己對(duì)業(yè)務(wù)、產(chǎn)品的把握也會(huì)有另一番的見解。雖然目前的這些努力未有很明顯的成效，但團(tuán)隊(duì)人員在產(chǎn)品設(shè)計(jì)、打磨、落地方面的能力得到了儲(chǔ)備，正所謂養(yǎng)兵千日，用在一時(shí)，相信未來可能將會(huì)有這些產(chǎn)品、人員發(fā)揮的地方。

小結(jié)一下，從帶技術(shù)到帶業(yè)務(wù)的一些努力：

1. 關(guān)注業(yè)務(wù)，從關(guān)注業(yè)務(wù)的數(shù)據(jù)、邏輯開始，并且多端的邏輯都需要熟悉
2. 技術(shù)項(xiàng)目與業(yè)務(wù)項(xiàng)目都要兩手抓，并且需要有自己團(tuán)隊(duì)主推落地的一些核心業(yè)務(wù)需求與優(yōu)化
3. 嘗試孵化與業(yè)務(wù)相關(guān)或者與公司發(fā)展戰(zhàn)略一致的產(chǎn)品

總結(jié)

來 Shopee 一年半，變化翻天覆地，從來不敢想象自己會(huì)有機(jī)會(huì)去突破這些職業(yè)的界限，或者摸到這些職業(yè)界限的天花板。希望這些粗淺的經(jīng)驗(yàn)?zāi)軌驅(qū)髞矶加行﹩l(fā)，也希望一些同行、前輩可以多多指點(diǎn)，不吝賜教。同時(shí)感謝我團(tuán)隊(duì)的同事與老板，這一年多以來對(duì)我不遺余力的支持！