淺談:前端如何賦能業(yè)務(wù)
你是否頭疼于,每天做不完的需求和改不完的bug?
你是否發(fā)愁,每天擼業(yè)務(wù)代碼,是否能獲得技術(shù)成長?
而追求成就感的你是否想過,你所編寫的一行行代碼,是在反復(fù)的變化中迅速成為遺留代碼,還是助公司插上騰飛的翅膀,在你死我活的戰(zhàn)場上脫穎而出?
因此本文會將業(yè)務(wù)和前端關(guān)聯(lián)起來討論,探討業(yè)務(wù)發(fā)展的不同時期,前端所能做的一些事情,既能解業(yè)務(wù)的困擾,也讓前端同學(xué)們擺脫碼工、切圖仔的定位。
千言萬語不如一張圖,全文完。
大誤,還是得詳細說說。
一、初始階段
在業(yè)務(wù)的初始階段,在市場定位、用戶訴求、產(chǎn)品邏輯已經(jīng)明確的前提下,此時業(yè)務(wù)的核心訴求是 『盡快上線』,進行快速驗證和產(chǎn)品迭代,當然,質(zhì)量還得能過得去。
所以此時技術(shù)同學(xué)的方案側(cè)重點是:
快、爽
先說『快』,在這種情況下,什么vue/react都見鬼去,老夫只用jQuery一把梭!
這是反面案例,這樣就只能重構(gòu)火葬場了,項目上線完就打包行李滾蛋……
此時的快,指的是 盡可能復(fù)用集團/業(yè)內(nèi)成熟的方案、架構(gòu),按捺住自己重新造輪子的躁動不安的心情。這又涉及到一個問題:如何選擇一個靠譜的方案?這是一個可以另開文章的話題,但先在此簡單說說根據(jù)我個人的經(jīng)驗,主要從穩(wěn)定性、可擴展性、性能去考慮。穩(wěn)定性 如何去評估?如果一個項目能做到這幾項,我是比較放心的。
- 項目star數(shù)多
 - 有單測,代碼覆蓋率90%~95%以上
 - 文檔完備,有常見Q&A
 - issue有較快的處理流程和周期,3天內(nèi)響應(yīng)、1~4周內(nèi)關(guān)閉。
 - 有穩(wěn)定的版本控制,不進行不兼容的升級,非要不兼容升級的話,將遷移工具做到最好。
 
可擴展性 如何評估?主要是指能否根據(jù)業(yè)務(wù)or已有技術(shù)方案,自定義部分內(nèi)容。
- 例如組件庫,是否能自定義主題、組件的事件回調(diào)等,因為有的需求,組件除了完成默認的行為,還需要執(zhí)行其他邏輯如埋點;
 - 例如單測工具,能否配置白名單,因為有一些代碼是兼容特殊場景,編寫用例模擬場景的成本實在比較高。這個主要是根據(jù)技術(shù)訴求和經(jīng)驗進行判斷。
 
性能問題,短期容易被人忽視,因為能跑就行,但一旦埋下隱患,日后有坑就極難解決。容易出現(xiàn)性能問題的地方有:代碼構(gòu)建、長列表/表格滾動、大數(shù)據(jù)圖表、復(fù)雜動畫、3D全景渲染等,如果所做的業(yè)務(wù)涉及到這幾個方面,選擇方案的時候就要特別注意性能。
如果實在圖省事兒,create-react-app、umi開箱即用來一套就完事兒了。
『爽』 這個字我的理解是,一款新產(chǎn)品出現(xiàn),一定需要在用戶體驗or交互上有絕對領(lǐng)先對手的地方。
一個我始終記憶猶新的例子,就是喬布斯發(fā)布第一款iPhone時,演示滑動列表時全場的驚呼,一個喬布斯的哥們說:當你滑動頁面的時候我就濕了。
另一個前端領(lǐng)域的例子,就是Ant Design。AntD被廣泛使用,很大一部分原因是其出色的視覺設(shè)計和動效。至今為止,AntD的官網(wǎng)介紹上仍然說這是一個設(shè)計體系。
所以我覺得,一款新產(chǎn)品,除了提供剛需價值,最好在美觀和易用上領(lǐng)先對手一大步,雖然主要還是看設(shè)計師和產(chǎn)品的功底,但前端同學(xué)的實現(xiàn)上至少不能拖后腿,不能加載太慢、滾動太卡。
藍海市場、剛需產(chǎn)品也許不那么看重這一點,但有的藍海門檻較低,很快就會轉(zhuǎn)變?yōu)榧t海。
還值得一提的是,賬戶體系的建設(shè),包括打通三方登錄、免登等(客戶端登錄態(tài)透傳到h5),網(wǎng)上不少資料,我實在沒這方面經(jīng)驗,就不在此多嘴了。
二、快速擴張
OK,假設(shè)產(chǎn)品如期上線,數(shù)據(jù)蹭蹭上漲,看起來一切都很好。
然后問題就來了,業(yè)務(wù)開始擴張,公司新招了100個運營和10個PD,你會發(fā)現(xiàn)需求突然就翻了10倍。這個時候我們怎么辦?
答案只有一個:提(jia)效(ren)。所以這個時期的核心是:
快、穩(wěn)
提效最簡單的辦法是加人,但問題是,100個運營好找,100個能寫出靠譜代碼的前端不好找,有的時候改別人的代碼,比重寫一遍更麻煩??催^《人月神話》的同學(xué)都知道,加人帶來的效率提升是有瓶頸的,人平均效率會隨著人數(shù)增加而下降。
此時就需要考慮通過技術(shù)手段提效,沉淀基礎(chǔ)研發(fā)體系,包括:
- 基礎(chǔ)工具庫+ 業(yè)務(wù)工具庫,避免重復(fù)寫一些簡單但是容易出bug的業(yè)務(wù)邏輯。
 - UI規(guī)范 + 組件體系。UI規(guī)范很重要,如果設(shè)計師不能達成一致,那出來的視覺稿必然是千差萬別的,你的公共組件也就難以沉淀了。
 - 研發(fā)工具升級。主要有 構(gòu)建性能優(yōu)化、數(shù)據(jù)mock工具、環(huán)境切換工具、線上問題排查工具等。
 
除了技術(shù)手段,人員的技術(shù)成長也很重要,畢竟技術(shù)方案是由人來執(zhí)行的,個人覺得常用的方式有:
- CodeReview,幫助新人快速成長到一定水平,保證新人開發(fā)代碼的可維護性。
 - 內(nèi)部分享。分享好用工具以提升研發(fā)效率,分享底層原理避免踩更深的坑浪費大量時間,也可以分享一些編碼、調(diào)試小技巧。
 
當然,還有一個提效的神技,就是——砍需求。
砍需求也是一門技術(shù)活兒,有的高級工程師用嘴就將需求解了。但不是每個團隊都采用放權(quán)式管理(此處感謝我的歷任老板們),給你足夠的權(quán)力自己砍需求和排期;有的公司采用的是集權(quán)式管理,只有前端leader能夠砍需求和進行任務(wù)分配,也使得不少同學(xué)這方面能力沒成長起來。
那么需求到底怎么砍?聽我簡單說一下,歡迎更好的套路。
- 首先,端正心態(tài)。你砍需求不是為了自己偷懶要早下班,你砍需求是為了業(yè)務(wù)整體效率的提升。你要砍的是無效需求、重復(fù)需求,公司業(yè)務(wù)的核心需求不能砍。不然你把公司業(yè)務(wù)都砍死了,自己喝西北風(fēng)去?公司如果運氣好IPO了,你不也爽一波?
 - 其次,先問問需求解決的業(yè)務(wù)問題是什么?搞清楚這一點,就能判斷:這個需求的優(yōu)先級多高、是不是偽/重復(fù)需求、是否有其他方式替代解決。此處的偽需求,是指不能實際解決用戶問題的需求。
 - 再其次,數(shù)據(jù)說話。相關(guān)的數(shù)據(jù)是怎么樣的?如何推導(dǎo)出業(yè)務(wù)的問題所在?做完這個需求數(shù)據(jù)會變成什么樣?
 - 最后,這個需求可能需要哪些上下游合作。涉及其他環(huán)節(jié)的需求,一定要將上下游拉到一起,考慮到所有可能的問題,統(tǒng)一一個方案,才能客觀評估工作量。
 - 最后的最后,也是最重要的,將共性的需求沉淀,構(gòu)建組件體系or業(yè)務(wù)模塊體系。有這個沉淀,才能更進一步,對需求做收斂,例如總不能說,已經(jīng)有一個slider模塊了,你還要再做一個類似的吧,對業(yè)務(wù)的提升到底在哪?
 
一般一個重要的、合理的需求都能比較好回答上面這些的問題。其中第三點,數(shù)據(jù)說話,也對公司的數(shù)據(jù)化能力提出了要求。
- 最基本的pv/uv、uv點擊率、停留時長,這是和前端頁面相關(guān)的指標。
 - 模塊熱度、功能使用情況。(上次做的功能你們又不用!)
 - 還有業(yè)務(wù)指標,例如電商的gmv、售罄率,但這些和前端沒直接關(guān)系。
 - 高級一點可以玩GrowthHack,全鏈路監(jiān)控細分用戶群的使用情況,比較適合業(yè)務(wù)已經(jīng)增長到一定體量,精細化運營的場景。
 - 大數(shù)據(jù)分析+洞察+數(shù)據(jù)可視化。會在第三部分講述。
 
另一個不能忽視的是,如何變得更『穩(wěn)』,因為大家都很急,一急就容易出線上故障,然后時間都花在處理故障上了,然后時間就更急,一個快速腐化的死循環(huán),然后你能怎么辦呢?只能以猝死明志啊……常見的有以下幾種方法:
研發(fā)流程管控。不經(jīng)測試不允許上線,這也是阿里的研發(fā)紅線,看起來是效率降低的,但其實只是把處理線上問題的時間用來測試了而已。
基礎(chǔ)庫、基礎(chǔ)組件 上單元測試,代碼覆蓋率90%+
監(jiān)控。線上404、頁面白屏、js/接口報錯等。
安全。最基本的xss、csrf做一下,再整體升一下https
問題復(fù)盤、沉淀機制。避免再出同樣的問題。
以上這些問題解決了,前端同學(xué)也就算是又快又穩(wěn)地幫業(yè)務(wù)度過了快速發(fā)展期,迎來業(yè)務(wù)的精耕細作期。
三、精耕細作
俗話說得好:攻城容易守成難,但現(xiàn)在攻城也不那么容易了?,F(xiàn)在新興的獨角獸,背后都有AT的影子,例如ofo和摩拜,雙方都極難一下子摁死對方。而是互拼內(nèi)力,最后很可能落得兩敗俱傷。這個時候我們就需要穩(wěn)中求快。
前兩個階段的C端場景看起來和前端關(guān)系更加緊密,那么這個階段和前端有什么關(guān)系呢?我覺得能做的事情有:
中后臺系統(tǒng)的構(gòu)建。將運營們的工作線上化,同時減少部分手工操作,達到效率的提升。
雖然說運營們通常excel用得虎虎生風(fēng),但有容易出錯、貪腐較多的問題,想想ofo被曝貪腐嚴重的新聞。
在不少缺前端的公司,這部分通常也由后端用jQuery一把梭。但后端擼出來系統(tǒng),通常都欠缺交互意識(無導(dǎo)航、報錯信息等設(shè)計)、擼不出稍微復(fù)雜的布局(見過被float和flex難住的)、缺少動效、SPA 等,做出來的系統(tǒng)真的差不少,都9012年了,還是讓專人來干這活吧。記得加上水印,包括明水印和暗水印,便于公司時候追責,間接防止公司機密外泄。
大數(shù)據(jù)可視化。不僅僅是消費者端頁面的訪問數(shù)據(jù),還有更深層次的公司運營數(shù)據(jù)。例如ofo可以實時跟蹤自行車的損壞率、監(jiān)控車輛密集程度等,從而指揮調(diào)度車的調(diào)度,達到車輛投放和使用率的最佳匹配。雖然這事兒吧,核心還是數(shù)據(jù)同學(xué)產(chǎn)出數(shù)據(jù)的準確性,但前端同學(xué)的配合是不可或缺的。
常見的可以用來做這事兒的有Echarts、HighCharts、G2等等,雖然我們基本不可能再重復(fù)自研一套,但取其精華,快速賦能業(yè)務(wù),就是業(yè)務(wù)前端的價值所在。
平臺化。此處其實指的是大中臺、小前臺的概念。因為我們往往已經(jīng)積累了一批中后臺系統(tǒng),但如何使同一個系統(tǒng)更快支撐新的業(yè)務(wù)、砍掉/合并重復(fù)功能的中后臺系統(tǒng),也是輔助業(yè)務(wù)的一種手段。
ABTest。根據(jù)之前的經(jīng)驗,電商不同行業(yè)的不同人群,對于交互設(shè)計的偏好真的就不一樣,有的喜歡大圖,有的喜歡小圖。因此通過ABTest方案,對人群進行千人千面的細分展現(xiàn),對業(yè)務(wù)也是可以稍微有一定的提升。
容器技術(shù)(hybrid & 內(nèi)核)& 極致性能。其實也就這么提一下,因為對于大多數(shù)公司,真沒有深入追求瀏覽器內(nèi)核提升的價值和可能性。hybrid方案是有必要的,但應(yīng)該在急劇擴張時期就做得差不多了。極致性能也屬于比較炫技的東西了(已經(jīng)做到1~2s頁面可交互的前提下),短期內(nèi)沒有特別大的必要,但在追求極致性能的過程中,迫使相關(guān)同學(xué)深入了解容器技術(shù)、服務(wù)端、網(wǎng)關(guān)、cdn等底層,并推動相關(guān)方升級,經(jīng)過長時間的積累,帶來人力儲備和技術(shù)儲備的提升。
四、新賽道、新增量時期
基本上做完上面那些東西,公司的業(yè)務(wù)進入一個穩(wěn)定的時期,就是到處看看有什么新的東西可以做了。(當然還是可能有各種各樣蛋碎的改版)核心
端的擴展
包括各類小程序。名義上是便于管控第三方,提供更好的體驗,其實就是人為割裂出一個端,同時用流量把這個端喂起來。不過沒辦法,誰讓爸爸們有流量呢。但注意一點,擴展一個端是有維護成本的,且并不會直接帶來流量收益,需要配套的運營計劃。
3D、全景、VR / AR 。有可能帶來交互根本變化的東西,缺點是科技還不夠先進,做全景素材成本很高,VR/AR的應(yīng)用場景也不夠多。
Flutter。
智能化
業(yè)務(wù)的智能化。例如活動界面的千人千面,根據(jù)算法計算出最佳界面元素組合方式等。
研發(fā)的智能化。例如FB的Aroma、之前業(yè)內(nèi)的psd2html,但這個算法和普通的電商推薦算法相比,最大的區(qū)別在于容錯率極低,你推薦錯了一個商品大不了不買看下一個,但你自動生成錯了一句代碼,整個系統(tǒng)就跑不起來。
實在不知道前端還有什么新的東西好關(guān)注的了,硬掰不出來,就這樣吧,歡迎指點。
五、最后
讀完本文,相信你已經(jīng)找到了前面三個問題的答案,能夠不再被一堆需求推著走,也能夠不再只擼業(yè)務(wù)代碼,孕育出屬于你們團隊的技術(shù)方案而獲得技術(shù)上的提升,最重要的是找到自己的一身本領(lǐng)在這個商業(yè)世界中的價值,不忘極客夢,技術(shù)改變世界,rock the world。
















 
 
 















 
 
 
 