淺談：前端如何賦能業務

你是否頭疼於，天天作不完的需求和改不完的bug？

你是否發愁，天天擼業務代碼，是否能得到技術成長？

而追求成就感的你是否想過，你所編寫的一行行代碼，是在反覆的變化中迅速成爲遺留代碼，仍是助公司插上騰飛的翅膀，在你死我活的戰場上脫穎而出？

所以本文會將業務和前端關聯起來討論，探討業務發展的不一樣時期，前端所能作的一些事情，既能解業務的困擾，也讓前端同窗們擺脫碼工、切圖仔的定位。

千言萬語不如一張圖，全文完。

大誤，仍是得詳細說說。

1、初始階段

在業務的初始階段，在市場定位、用戶訴求、產品邏輯已經明確的前提下，此時業務的核心訴求是 『儘快上線』，進行快速驗證和產品迭代，固然，質量還得能過得去。 因此此時技術同窗的方案側重點是：

快、爽

先說『快』，在這種狀況下，什麼vue/react都見鬼去，老夫只用jQuery一把梭！ 這是反面案例，這樣就只能重構火葬場了，項目上線完就打包行李滾蛋……

此時的快，指的是 儘量複用集團/業內成熟的方案、架構，按捺住本身從新造輪子的躁動不安的心情。 這又涉及到一個問題：如何選擇一個靠譜的方案？這是一個能夠另開文章的話題，但先在此簡單說說 根據我我的的經驗，主要從穩定性、可擴展性、性能去考慮。

穩定性 如何去評估？若是一個項目能作到這幾項，我是比較放心的。

1. 項目star數多
2. 有單測，代碼覆蓋率90%~95%以上
3. 文檔完備，有常見Q&A
4. issue有較快的處理流程和週期，3天內響應、1~4周內關閉。
5. 有穩定的版本控制，不進行不兼容的升級，非要不兼容升級的話，將遷移工具作到極致。

可擴展性 如何評估？主要是指可否根據業務or已有技術方案，自定義部份內容。

1. 例如組件庫，是否能自定義主題、組件的事件回調等，由於有的需求，組件除了完成默認的行爲，還須要執行其餘邏輯如埋點；
2. 例如單測工具，可否配置白名單，由於有一些代碼是兼容特殊場景，編寫用例模擬場景的成本實在比較高。這個主要是根據技術訴求和經驗進行判斷。

性能問題，短時間容易被人忽視，由於能跑就行，但一旦埋下隱患，往後有坑就極難解決。容易出現性能問題的地方有：代碼構建、長列表/表格滾動、大數據圖表、複雜動畫、3D全景渲染等，若是所作的業務涉及到這幾個方面，選擇方案的時候就要特別注意性能。

若是實在圖省事兒，create-react-app、umi開箱即用來一套就完事兒了。

『爽』 這個字個人理解是，一款新產品出現，必定須要在用戶體驗or交互上有絕對領先對手的地方。

一個我始終記憶猶新的例子，就是喬布斯發佈第一款iPhone時，演示滑動列表時全場的驚呼，一個喬布斯的哥們說：當你滑動頁面的時候我就溼了。

另外一個前端領域的例子，就是Ant Design。AntD被普遍使用，很大一部分緣由是其出色的視覺設計和動效。至今爲止，AntD的官網介紹上仍然說這是一個設計體系。

因此我以爲，一款新產品，除了提供剛需價值，最好在美觀和易用上領先對手一大步，雖然主要仍是看設計師和產品的功底，但前端同窗的實現上至少不能拖後腿，不能加載太慢、滾動太卡。

藍海市場、剛需產品也許不那麼看重這一點，但有的藍海門檻較低，很快就會轉變爲紅海。

還值得一提的是，帳戶體系的建設，包括打通三方登陸、免登等（客戶端登陸態透傳到h5），網上很多資料，我實在沒這方面經驗，就不在此多嘴了。

2、快速擴張

OK，假設產品如期上線，數據蹭蹭上漲，看起來一切都很完美。 而後問題就來了，業務開始擴張，公司新招了100個運營和10個PD，你會發現需求忽然就翻了10倍。這個時候咱們怎麼辦？

答案只有一個：提（jia）效（ren）。因此這個時期的核心是：

快、穩

提效最簡單的辦法是加人，但問題是，100個運營好找，100個能寫出靠譜代碼的前端很差找，有的時候改別人的代碼，比重寫一遍更麻煩。看過《人月神話》的同窗都知道，加人帶來的效率提高是有瓶頸的，人平均效率會隨着人數增長而降低。

此時就須要考慮經過技術手段提效，沉澱基礎研發體系，包括：

1. 基礎工具庫+ 業務工具庫，避免重複寫一些簡單可是容易出bug的業務邏輯。
2. UI規範 + 組件體系。UI規範很重要，若是設計師不能達成一致，那出來的視覺稿必然是千差萬別的，你的公共組件也就難以沉澱了。
3. 研發工具升級。主要有 構建性能優化、數據mock工具、環境切換工具、線上問題排查工具等。

除了技術手段，人員的技術成長也很重要，畢竟技術方案是由人來執行的，我的以爲經常使用的方式有：

1. CodeReview，幫助新人快速成長到必定水平，保證新人開發代碼的可維護性。
2. 內部分享。分享好用工具以提高研發效率，分享底層原理避免踩更深的坑浪費大量時間，也能夠分享一些編碼、調試小技巧。

固然，還有一個提效的神技，就是——砍需求。

砍需求也是一門技術活兒，有的高級工程師用嘴就將需求解了。但不是每一個團隊都採用放權式管理（此處感謝個人歷任老闆們），給你足夠的權力本身砍需求和排期； 有的公司採用的是集權式管理，只有前端leader可以砍需求和進行任務分配，也使得很多同窗這方面能力沒成長起來。

那麼需求到底怎麼砍？聽我簡單說一下，歡迎更好的套路。

1. 首先，端正心態。 你砍需求不是爲了本身偷懶要早下班，你砍需求是爲了業務總體效率的提高。你要砍的是無效需求、重複需求，公司業務的核心需求不能砍。否則你把公司業務都砍死了，本身喝西北風去？公司若是運氣好IPO了，你不也爽一波？
2. 其次，先問問需求解決的業務問題是什麼？ 搞清楚這一點，就能判斷：這個需求的優先級多高、是否是僞/重複需求、是否有其餘方式替代解決。此處的僞需求，是指不能實際解決用戶問題的需求。
3. 再其次，數聽說話。 相關的數據是怎麼樣的？如何推導出業務的問題所在？作完這個需求數據會變成什麼樣？
4. 最後，這個需求可能須要哪些上下游合做。涉及其餘環節的需求，必定要將上下游拉到一塊兒，考慮到全部可能的問題，統一一個方案，才能客觀評估工做量。
5. 最後的最後，也是最重要的，將共性的需求沉澱，構建組件體系or業務模塊體系。有這個沉澱，才能更進一步，對需求作收斂，例如總不能說，已經有一個slider模塊了，你還要再作一個相似的吧，對業務的提高到底在哪？

通常一個重要的、合理的需求都能比較好回答上面這些的問題。其中第三點，數聽說話，也對公司的數據化能力提出了要求。

1. 最基本的pv/uv、uv點擊率、停留時長，這是和前端頁面相關的指標。
2. 模塊熱度、功能使用狀況，這是用來和業務方撕逼的時候使用的。（上次作的功能大家又不用！）
3. 還有業務指標，例如電商的gmv、售罄率，但這些和前端沒直接關係。
4. 高級一點能夠玩GrowthHack，全鏈路監控細分用戶羣的使用狀況，比較適合業務已經增加到必定體量，精細化運營的場景。
5. 大數據分析+洞察+數據可視化。會在第三部分講述。

另外一個不能忽視的是，如何變得更『穩』，由於你們都很急，一急就容易出線上故障，而後時間都花在處理故障上了，而後時間就更急，一個快速腐化的死循環，而後你能怎麼辦呢？只能以猝死明志啊……常見的有如下幾種方法：

1. 研發流程管控。不經測試不容許上線，這也是阿里的研發紅線，看起來是效率下降的，但其實只是把處理線上問題的時間用來測試了而已。
2. 基礎庫、基礎組件 上單元測試，代碼覆蓋率90%+
3. 監控。線上40四、頁面白屏、js/接口報錯等。
4. 安全。最基本的xss、csrf作一下，再總體升一下https
5. 問題覆盤、沉澱機制。避免再出一樣的問題。

以上這些問題解決了，前端同窗也就算是又快又穩地幫業務度過了快速發展期，迎來業務的精耕細做期。

3、精耕細做

俗話說得好：攻城容易守成難，但如今攻城也不那麼容易了。如今新興的獨角獸，背後都有AT的影子，例如ofo和摩拜，雙方都極難一會兒摁死對方。而是互拼內力，最後極可能落得兩敗俱傷。這個時候咱們就須要穩中求快。

前兩個階段的C端場景看起來和前端關係更加緊密，那麼這個階段和前端有什麼關係呢？我以爲能作的事情有：

1. 中後臺系統的構建。 將運營們的工做線上化，同時減小部分手工操做，達到效率的提高。 雖說運營們一般excel用得虎虎生風，但有容易出錯、貪腐較多的問題，想一想ofo被曝貪腐嚴重的新聞。 在很多缺前端的公司，這部分一般也由後端用jQuery一把梭。但後端擼出來系統，一般都欠缺交互意識（無導航、報錯信息等設計）、擼不出稍微複雜的佈局（見過被float和flex難住的）、缺乏動效、SPA 等，作出來的系統真的差很多，都9012年了，仍是讓專人來幹這活吧。記得加上水印，包括明水印和暗水印，便於公司時候追責，間接防止公司機密外泄。

2. 大數據可視化。 不只僅是消費者端頁面的訪問數據，還有更深層次的公司運營數據。例如ofo能夠實時跟蹤自行車的損壞率、監控車輛密集程度等，從而指揮調度車的調度，達到車輛投放和使用率的最佳匹配。雖然這事兒吧，核心仍是數據同窗產出數據的準確性，但前端同窗的配合是不可或缺的。 常見的能夠用來作這事兒的有Echarts、HighCharts、G2等等，雖然咱們基本不可能再重複自研一套，但取其精華，快速賦能業務，就是業務前端的價值所在。

3. 平臺化。 此處其實指的是大中臺、小前臺的概念。由於咱們每每已經積累了一批中後臺系統，但如何使同一個系統更快支撐新的業務、砍掉/合併重複功能的中後臺系統，也是輔助業務的一種手段。

4. ABTest。 根據以前的經驗，電商不一樣行業的不一樣人羣，對於交互設計的偏好真的就不同，有的喜歡大圖，有的喜歡小圖。所以經過ABTest方案，對人羣進行千人千面的細分展示，對業務也是能夠稍微有必定的提高。

5. 容器技術（hybrid & 內核）& 極致性能。 其實也就這麼提一下，由於對於大多數公司，真沒有深刻追求瀏覽器內核提高的價值和可能性。 hybrid方案是有必要的，但應該在急劇擴張時期就作得差很少了。 極致性能也屬於比較炫技的東西了（已經作到1~2s頁面可交互的前提下），短時間內沒有特別大的必要，但在追求極致性能的過程當中，迫使相關同窗深刻了解容器技術、服務端、網關、cdn等底層，並推進相關方升級，通過長時間的積累，帶來人力儲備和技術儲備的提高。

4、新賽道、新增量時期

基本上作完上面那些東西，公司的業務進入一個穩定的時期，就是處處看看有什麼新的東西能夠作了。（固然仍是可能有各類各樣蛋碎的改版） 核心

1. 端的擴展：
   1. 包括各種小程序。 名義上是便於管控第三方，提供更好的體驗，其實就是人爲割裂出一個端，同時用流量把這個端喂起來。不過沒辦法，誰讓爸爸們有流量呢。但注意一點，擴展一個端是有維護成本的，且並不會直接帶來流量收益，須要配套的運營計劃。
   2. 3D、全景、VR / AR 。有可能帶來交互根本變化的東西，惟一的缺點是科技還不夠先進，作全景素材成本很高，VR/AR的應用場景也不夠多。
   3. Flutter。
2. 智能化：
   1. 業務的智能化。例如活動界面的千人千面，根據算法計算出最佳界面元素組合方式等。
   2. 研發的智能化。例如FB的Aroma、以前業內的psd2html，但這個算法和普通的電商推薦算法相比，最大的區別在於容錯率極低，你推薦錯了一個商品大不了不買看下一個，但你自動生成錯了一句代碼，整個系統就跑不起來。

實在不知道前端還有什麼新的東西好關注的了，硬掰不出來，就這樣吧，歡迎指點。

5、最後

讀完本文，相信你已經找到了前面三個問題的答案，可以再也不被一堆需求推着走，也可以再也不只擼業務代碼，孕育出屬於大家團隊的技術方案而得到技術上的提高，最重要的是找到本身的一身本領在這個商業世界中的價值，不忘極客夢，技術改變世界，rock the world。

免責免撕聲明：本文是我的的一些總結和思考，筆者的業務經驗有大流量產品、大型營銷活動、各種中後臺項目，基礎技術產品也搞過，但終究經驗有限，不免有錯漏，歡迎指正和補充。