你是否頭疼于，每天做不完的需求和改不完的bug?

你是否發(fā)愁，每天擼業(yè)務(wù)代碼，是否能獲得技術(shù)成長(zhǎng)?

而追求成就感的你是否想過(guò)，你所編寫的一行行代碼，是在反復(fù)的變化中迅速成為遺留代碼，還是助公司插上騰飛的翅膀，在你死我活的戰(zhàn)場(chǎng)上脫穎而出?

因此本文會(huì)將業(yè)務(wù)和前端關(guān)聯(lián)起來(lái)討論，探討業(yè)務(wù)發(fā)展的不同時(shí)期，前端所能做的一些事情，既能解業(yè)務(wù)的困擾，也讓前端同學(xué)們擺脫碼工、切圖仔的定位。

千言萬(wàn)語(yǔ)不如一張圖，全文完。

大誤，還是得詳細(xì)說(shuō)說(shuō)。

一、初始階段

在業(yè)務(wù)的初始階段，在市場(chǎng)定位、用戶訴求、產(chǎn)品邏輯已經(jīng)明確的前提下，此時(shí)業(yè)務(wù)的核心訴求是 『盡快上線』，進(jìn)行快速驗(yàn)證和產(chǎn)品迭代，當(dāng)然，質(zhì)量還得能過(guò)得去。

所以此時(shí)技術(shù)同學(xué)的方案?jìng)?cè)重點(diǎn)是：

快、爽

先說(shuō)『快』，在這種情況下，什么vue/react都見鬼去，老夫只用jQuery一把梭!

這是反面案例，這樣就只能重構(gòu)火葬場(chǎng)了，項(xiàng)目上線完就打包行李滾蛋……

此時(shí)的快，指的是 盡可能復(fù)用集團(tuán)/業(yè)內(nèi)成熟的方案、架構(gòu)，按捺住自己重新造輪子的躁動(dòng)不安的心情。這又涉及到一個(gè)問(wèn)題：如何選擇一個(gè)靠譜的方案?這是一個(gè)可以另開文章的話題，但先在此簡(jiǎn)單說(shuō)說(shuō)根據(jù)我個(gè)人的經(jīng)驗(yàn)，主要從穩(wěn)定性、可擴(kuò)展性、性能去考慮。穩(wěn)定性 如何去評(píng)估?如果一個(gè)項(xiàng)目能做到這幾項(xiàng)，我是比較放心的。

• 項(xiàng)目star數(shù)多
• 有單測(cè)，代碼覆蓋率90%~95%以上
• 文檔完備，有常見Q&A
• issue有較快的處理流程和周期，3天內(nèi)響應(yīng)、1~4周內(nèi)關(guān)閉。
• 有穩(wěn)定的版本控制，不進(jìn)行不兼容的升級(jí)，非要不兼容升級(jí)的話，將遷移工具做到最好。

可擴(kuò)展性 如何評(píng)估?主要是指能否根據(jù)業(yè)務(wù)or已有技術(shù)方案，自定義部分內(nèi)容。

• 例如組件庫(kù)，是否能自定義主題、組件的事件回調(diào)等，因?yàn)橛械男枨?，組件除了完成默認(rèn)的行為，還需要執(zhí)行其他邏輯如埋點(diǎn);
• 例如單測(cè)工具，能否配置白名單，因?yàn)橛幸恍┐a是兼容特殊場(chǎng)景，編寫用例模擬場(chǎng)景的成本實(shí)在比較高。這個(gè)主要是根據(jù)技術(shù)訴求和經(jīng)驗(yàn)進(jìn)行判斷。

性能問(wèn)題，短期容易被人忽視，因?yàn)槟芘芫托?，但一旦埋下隱患，日后有坑就極難解決。容易出現(xiàn)性能問(wèn)題的地方有：代碼構(gòu)建、長(zhǎng)列表/表格滾動(dòng)、大數(shù)據(jù)圖表、復(fù)雜動(dòng)畫、3D全景渲染等，如果所做的業(yè)務(wù)涉及到這幾個(gè)方面，選擇方案的時(shí)候就要特別注意性能。

如果實(shí)在圖省事兒，create-react-app、umi開箱即用來(lái)一套就完事兒了。

『爽』 這個(gè)字我的理解是，一款新產(chǎn)品出現(xiàn)，一定需要在用戶體驗(yàn)or交互上有絕對(duì)領(lǐng)先對(duì)手的地方。

一個(gè)我始終記憶猶新的例子，就是喬布斯發(fā)布第一款iPhone時(shí)，演示滑動(dòng)列表時(shí)全場(chǎng)的驚呼，一個(gè)喬布斯的哥們說(shuō)：當(dāng)你滑動(dòng)頁(yè)面的時(shí)候我就濕了。

[[281023]] 

另一個(gè)前端領(lǐng)域的例子，就是Ant Design。AntD被廣泛使用，很大一部分原因是其出色的視覺(jué)設(shè)計(jì)和動(dòng)效。至今為止，AntD的官網(wǎng)介紹上仍然說(shuō)這是一個(gè)設(shè)計(jì)體系。

所以我覺(jué)得，一款新產(chǎn)品，除了提供剛需價(jià)值，最好在美觀和易用上領(lǐng)先對(duì)手一大步，雖然主要還是看設(shè)計(jì)師和產(chǎn)品的功底，但前端同學(xué)的實(shí)現(xiàn)上至少不能拖后腿，不能加載太慢、滾動(dòng)太卡。

藍(lán)海市場(chǎng)、剛需產(chǎn)品也許不那么看重這一點(diǎn)，但有的藍(lán)海門檻較低，很快就會(huì)轉(zhuǎn)變?yōu)榧t海。

還值得一提的是，賬戶體系的建設(shè)，包括打通三方登錄、免登等(客戶端登錄態(tài)透?jìng)鞯絟5)，網(wǎng)上不少資料，我實(shí)在沒(méi)這方面經(jīng)驗(yàn)，就不在此多嘴了。

二、快速擴(kuò)張

OK，假設(shè)產(chǎn)品如期上線，數(shù)據(jù)蹭蹭上漲，看起來(lái)一切都很好。

然后問(wèn)題就來(lái)了，業(yè)務(wù)開始擴(kuò)張，公司新招了100個(gè)運(yùn)營(yíng)和10個(gè)PD，你會(huì)發(fā)現(xiàn)需求突然就翻了10倍。這個(gè)時(shí)候我們?cè)趺崔k?

答案只有一個(gè)：提(jia)效(ren)。所以這個(gè)時(shí)期的核心是：

快、穩(wěn)

提效最簡(jiǎn)單的辦法是加人，但問(wèn)題是，100個(gè)運(yùn)營(yíng)好找，100個(gè)能寫出靠譜代碼的前端不好找，有的時(shí)候改別人的代碼，比重寫一遍更麻煩?？催^(guò)《人月神話》的同學(xué)都知道，加人帶來(lái)的效率提升是有瓶頸的，人平均效率會(huì)隨著人數(shù)增加而下降。

此時(shí)就需要考慮通過(guò)技術(shù)手段提效，沉淀基礎(chǔ)研發(fā)體系，包括：

• 基礎(chǔ)工具庫(kù)+ 業(yè)務(wù)工具庫(kù)，避免重復(fù)寫一些簡(jiǎn)單但是容易出bug的業(yè)務(wù)邏輯。
• UI規(guī)范 + 組件體系。UI規(guī)范很重要，如果設(shè)計(jì)師不能達(dá)成一致，那出來(lái)的視覺(jué)稿必然是千差萬(wàn)別的，你的公共組件也就難以沉淀了。
• 研發(fā)工具升級(jí)。主要有 構(gòu)建性能優(yōu)化、數(shù)據(jù)mock工具、環(huán)境切換工具、線上問(wèn)題排查工具等。

除了技術(shù)手段，人員的技術(shù)成長(zhǎng)也很重要，畢竟技術(shù)方案是由人來(lái)執(zhí)行的，個(gè)人覺(jué)得常用的方式有：

• CodeReview，幫助新人快速成長(zhǎng)到一定水平，保證新人開發(fā)代碼的可維護(hù)性。
• 內(nèi)部分享。分享好用工具以提升研發(fā)效率，分享底層原理避免踩更深的坑浪費(fèi)大量時(shí)間，也可以分享一些編碼、調(diào)試小技巧。

當(dāng)然，還有一個(gè)提效的神技，就是——砍需求。

砍需求也是一門技術(shù)活兒，有的高級(jí)工程師用嘴就將需求解了。但不是每個(gè)團(tuán)隊(duì)都采用放權(quán)式管理(此處感謝我的歷任老板們)，給你足夠的權(quán)力自己砍需求和排期;有的公司采用的是集權(quán)式管理，只有前端leader能夠砍需求和進(jìn)行任務(wù)分配，也使得不少同學(xué)這方面能力沒(méi)成長(zhǎng)起來(lái)。

那么需求到底怎么砍?聽我簡(jiǎn)單說(shuō)一下，歡迎更好的套路。

• 首先，端正心態(tài)。你砍需求不是為了自己偷懶要早下班，你砍需求是為了業(yè)務(wù)整體效率的提升。你要砍的是無(wú)效需求、重復(fù)需求，公司業(yè)務(wù)的核心需求不能砍。不然你把公司業(yè)務(wù)都砍死了，自己喝西北風(fēng)去?公司如果運(yùn)氣好IPO了，你不也爽一波?
• 其次，先問(wèn)問(wèn)需求解決的業(yè)務(wù)問(wèn)題是什么?搞清楚這一點(diǎn)，就能判斷：這個(gè)需求的優(yōu)先級(jí)多高、是不是偽/重復(fù)需求、是否有其他方式替代解決。此處的偽需求，是指不能實(shí)際解決用戶問(wèn)題的需求。
• 再其次，數(shù)據(jù)說(shuō)話。相關(guān)的數(shù)據(jù)是怎么樣的?如何推導(dǎo)出業(yè)務(wù)的問(wèn)題所在?做完這個(gè)需求數(shù)據(jù)會(huì)變成什么樣?
• 最后，這個(gè)需求可能需要哪些上下游合作。涉及其他環(huán)節(jié)的需求，一定要將上下游拉到一起，考慮到所有可能的問(wèn)題，統(tǒng)一一個(gè)方案，才能客觀評(píng)估工作量。
• 最后的最后，也是最重要的，將共性的需求沉淀，構(gòu)建組件體系or業(yè)務(wù)模塊體系。有這個(gè)沉淀，才能更進(jìn)一步，對(duì)需求做收斂，例如總不能說(shuō)，已經(jīng)有一個(gè)slider模塊了，你還要再做一個(gè)類似的吧，對(duì)業(yè)務(wù)的提升到底在哪?

一般一個(gè)重要的、合理的需求都能比較好回答上面這些的問(wèn)題。其中第三點(diǎn)，數(shù)據(jù)說(shuō)話，也對(duì)公司的數(shù)據(jù)化能力提出了要求。

• 最基本的pv/uv、uv點(diǎn)擊率、停留時(shí)長(zhǎng)，這是和前端頁(yè)面相關(guān)的指標(biāo)。
• 模塊熱度、功能使用情況。(上次做的功能你們又不用!)
• 還有業(yè)務(wù)指標(biāo)，例如電商的gmv、售罄率，但這些和前端沒(méi)直接關(guān)系。
• 高級(jí)一點(diǎn)可以玩GrowthHack，全鏈路監(jiān)控細(xì)分用戶群的使用情況，比較適合業(yè)務(wù)已經(jīng)增長(zhǎng)到一定體量，精細(xì)化運(yùn)營(yíng)的場(chǎng)景。
• 大數(shù)據(jù)分析+洞察+數(shù)據(jù)可視化。會(huì)在第三部分講述。

另一個(gè)不能忽視的是，如何變得更『穩(wěn)』，因?yàn)榇蠹叶己芗保患本腿菀壮鼍€上故障，然后時(shí)間都花在處理故障上了，然后時(shí)間就更急，一個(gè)快速腐化的死循環(huán)，然后你能怎么辦呢?只能以猝死明志啊……常見的有以下幾種方法：

研發(fā)流程管控。不經(jīng)測(cè)試不允許上線，這也是阿里的研發(fā)紅線，看起來(lái)是效率降低的，但其實(shí)只是把處理線上問(wèn)題的時(shí)間用來(lái)測(cè)試了而已。

基礎(chǔ)庫(kù)、基礎(chǔ)組件 上單元測(cè)試，代碼覆蓋率90%+

監(jiān)控。線上404、頁(yè)面白屏、js/接口報(bào)錯(cuò)等。

安全。最基本的xss、csrf做一下，再整體升一下https

問(wèn)題復(fù)盤、沉淀機(jī)制。避免再出同樣的問(wèn)題。

以上這些問(wèn)題解決了，前端同學(xué)也就算是又快又穩(wěn)地幫業(yè)務(wù)度過(guò)了快速發(fā)展期，迎來(lái)業(yè)務(wù)的精耕細(xì)作期。

三、精耕細(xì)作

俗話說(shuō)得好：攻城容易守成難，但現(xiàn)在攻城也不那么容易了?，F(xiàn)在新興的獨(dú)角獸，背后都有AT的影子，例如ofo和摩拜，雙方都極難一下子摁死對(duì)方。而是互拼內(nèi)力，最后很可能落得兩敗俱傷。這個(gè)時(shí)候我們就需要穩(wěn)中求快。

[[281024]] 

前兩個(gè)階段的C端場(chǎng)景看起來(lái)和前端關(guān)系更加緊密，那么這個(gè)階段和前端有什么關(guān)系呢?我覺(jué)得能做的事情有：

中后臺(tái)系統(tǒng)的構(gòu)建。將運(yùn)營(yíng)們的工作線上化，同時(shí)減少部分手工操作，達(dá)到效率的提升。

雖然說(shuō)運(yùn)營(yíng)們通常excel用得虎虎生風(fēng)，但有容易出錯(cuò)、貪腐較多的問(wèn)題，想想ofo被曝貪腐嚴(yán)重的新聞。

在不少缺前端的公司，這部分通常也由后端用jQuery一把梭。但后端擼出來(lái)系統(tǒng)，通常都欠缺交互意識(shí)(無(wú)導(dǎo)航、報(bào)錯(cuò)信息等設(shè)計(jì))、擼不出稍微復(fù)雜的布局(見過(guò)被float和flex難住的)、缺少動(dòng)效、SPA 等，做出來(lái)的系統(tǒng)真的差不少，都9012年了，還是讓專人來(lái)干這活吧。記得加上水印，包括明水印和暗水印，便于公司時(shí)候追責(zé)，間接防止公司機(jī)密外泄。

大數(shù)據(jù)可視化。不僅僅是消費(fèi)者端頁(yè)面的訪問(wèn)數(shù)據(jù)，還有更深層次的公司運(yùn)營(yíng)數(shù)據(jù)。例如ofo可以實(shí)時(shí)跟蹤自行車的損壞率、監(jiān)控車輛密集程度等，從而指揮調(diào)度車的調(diào)度，達(dá)到車輛投放和使用率的最佳匹配。雖然這事兒吧，核心還是數(shù)據(jù)同學(xué)產(chǎn)出數(shù)據(jù)的準(zhǔn)確性，但前端同學(xué)的配合是不可或缺的。

常見的可以用來(lái)做這事兒的有Echarts、HighCharts、G2等等，雖然我們基本不可能再重復(fù)自研一套，但取其精華，快速賦能業(yè)務(wù)，就是業(yè)務(wù)前端的價(jià)值所在。

平臺(tái)化。此處其實(shí)指的是大中臺(tái)、小前臺(tái)的概念。因?yàn)槲覀兺呀?jīng)積累了一批中后臺(tái)系統(tǒng)，但如何使同一個(gè)系統(tǒng)更快支撐新的業(yè)務(wù)、砍掉/合并重復(fù)功能的中后臺(tái)系統(tǒng)，也是輔助業(yè)務(wù)的一種手段。

ABTest。根據(jù)之前的經(jīng)驗(yàn)，電商不同行業(yè)的不同人群，對(duì)于交互設(shè)計(jì)的偏好真的就不一樣，有的喜歡大圖，有的喜歡小圖。因此通過(guò)ABTest方案，對(duì)人群進(jìn)行千人千面的細(xì)分展現(xiàn)，對(duì)業(yè)務(wù)也是可以稍微有一定的提升。

容器技術(shù)(hybrid & 內(nèi)核)& 極致性能。其實(shí)也就這么提一下，因?yàn)閷?duì)于大多數(shù)公司，真沒(méi)有深入追求瀏覽器內(nèi)核提升的價(jià)值和可能性。hybrid方案是有必要的，但應(yīng)該在急劇擴(kuò)張時(shí)期就做得差不多了。極致性能也屬于比較炫技的東西了(已經(jīng)做到1~2s頁(yè)面可交互的前提下)，短期內(nèi)沒(méi)有特別大的必要，但在追求極致性能的過(guò)程中，迫使相關(guān)同學(xué)深入了解容器技術(shù)、服務(wù)端、網(wǎng)關(guān)、cdn等底層，并推動(dòng)相關(guān)方升級(jí)，經(jīng)過(guò)長(zhǎng)時(shí)間的積累，帶來(lái)人力儲(chǔ)備和技術(shù)儲(chǔ)備的提升。

四、新賽道、新增量時(shí)期

基本上做完上面那些東西，公司的業(yè)務(wù)進(jìn)入一個(gè)穩(wěn)定的時(shí)期，就是到處看看有什么新的東西可以做了。(當(dāng)然還是可能有各種各樣蛋碎的改版)核心

端的擴(kuò)展

包括各類小程序。名義上是便于管控第三方，提供更好的體驗(yàn)，其實(shí)就是人為割裂出一個(gè)端，同時(shí)用流量把這個(gè)端喂起來(lái)。不過(guò)沒(méi)辦法，誰(shuí)讓爸爸們有流量呢。但注意一點(diǎn)，擴(kuò)展一個(gè)端是有維護(hù)成本的，且并不會(huì)直接帶來(lái)流量收益，需要配套的運(yùn)營(yíng)計(jì)劃。

3D、全景、VR / AR 。有可能帶來(lái)交互根本變化的東西，缺點(diǎn)是科技還不夠先進(jìn)，做全景素材成本很高，VR/AR的應(yīng)用場(chǎng)景也不夠多。

Flutter。

智能化

業(yè)務(wù)的智能化。例如活動(dòng)界面的千人千面，根據(jù)算法計(jì)算出最佳界面元素組合方式等。

研發(fā)的智能化。例如FB的Aroma、之前業(yè)內(nèi)的psd2html，但這個(gè)算法和普通的電商推薦算法相比，最大的區(qū)別在于容錯(cuò)率極低，你推薦錯(cuò)了一個(gè)商品大不了不買看下一個(gè)，但你自動(dòng)生成錯(cuò)了一句代碼，整個(gè)系統(tǒng)就跑不起來(lái)。

實(shí)在不知道前端還有什么新的東西好關(guān)注的了，硬掰不出來(lái)，就這樣吧，歡迎指點(diǎn)。

五、最后

讀完本文，相信你已經(jīng)找到了前面三個(gè)問(wèn)題的答案，能夠不再被一堆需求推著走，也能夠不再只擼業(yè)務(wù)代碼，孕育出屬于你們團(tuán)隊(duì)的技術(shù)方案而獲得技術(shù)上的提升，最重要的是找到自己的一身本領(lǐng)在這個(gè)商業(yè)世界中的價(jià)值，不忘極客夢(mèng)，技術(shù)改變世界，rock the world。