在 2020 年剛加入公司的時候，我就確定要持續推進基建的建設，經過這幾年的沉淀，完成了從 0 到 1 的跨越。   基建的目的是解決各類技術或業務問題，沉淀通用技術能力，提升工作效率，降低開發成本，直接或間接助力業務開展。   接下來會圍繞項目重構、組件化、標準化、工具化、自動化、文檔化和頁面規范化幾個方面來探討基建。 ## 一、項目重構   項目重構一方面是為了延緩代碼的腐爛，另一方面也是為了能享受新技術帶來的新體驗。   剛進公司時發現共存著好多個技術棧，有 jQuery、React、Vue 等，還遺留了許多祖傳代碼，還有混合式架構。   所謂混合式架構就是類似于老早的 PHP 寫法，一張 php 頁面中混雜著前端代碼和 PHP 后端代碼。   還有 jQuery 這塊，是最老舊的代碼，本來想制訂一份遷移計劃，消滅 jQuery 和混合式架構，但發現成本巨大。   因為很多項目都不再維護了，只要穩定運行即可，所以就放棄了大規模的遷移，只是不在做新增，只做存量維護。   對于業務方來說，他們并不關心你的技術棧是新還是舊，他們只要求業務能保持穩定，并且還能持續迭代更新。   所以在做技術棧升級時，需要保證能達到這兩點。   Vue3 正式版發布后，自己團隊也躍躍欲試，原先是計劃直接升級，但調研后發現成本比較高。   所以仍然采取之前的策略，現在重新創建一個項目，新需求往這里塞。   當出現巨石應用時，可以引入微前端，將應用切分，讓其更容易維護。 ## 二、文檔化   文檔匱乏，這是我進公司的第一印象，剛進公司的那幾個月，我就開始著手搭建文檔體系，一直到現在還在補充中，這是一個長期的工作。 **1）文檔分類**   剛進來，就有一個小伙要離職了，我讓他在走之前補充了各個項目的文檔，因為他是個老員工，都比較熟悉。   我在此基礎上，又分別新增了規范、業務邏輯、技術文檔、疑難雜癥等欄目，規范包括代碼規范、協作規范、開發流程等規范。   開啟周會制度，每周五早上小組成員在一起開個短會，信息同步，溝通問題，大家都彼此都能有更進一步的了解。   在會議中將探討本周遇到的各類問題，以及解決策略，近期公司動向也會與成員同步，自己也會時不時的強調文檔的重要性。   在自己的影響下，組內成員也在慢慢完善各類文檔，也會有意識的去補充沒有的文檔，并且去將開發過程中遇到的問題做單獨記錄，匯總到各個項目的疑難雜癥中。   2022 年 5月中旬，公司將之前存放在 wiki 中的文檔整體遷移至飛書文檔中，我對整體的目錄也做了一次細致的歸類，便于查看。   改成飛書后，有個很大的好處，就是可以直接用手機瀏覽文檔了，文檔格式也比之前的 confluence 美觀。 **2）活文檔**   最近還學到了個新名詞：活文檔，就是將記錄寫在事物本身中，例如代碼中的注釋、版本提交時的 message 等。   我們組今年也在進一步規范這類活文檔，減少信息障礙。 **3）技術分享**   技術分享一開始是整個技術部參與，但是參與度不高，后面就改成了我們組內部做技術分享。   每個人都會輪到，兩周一次，技術范圍不限制，這樣大家都能參與進來，已經進行了六十多場，每場結束后，都會將內容留檔。   大家對此類技術分享并不排斥，都會積極準備，有源碼分析、案例分享、庫的使用等。 **4）Code Review**   2022 年的 5 月份的時候發生了幾場事故，問題雖然低級，但造成的危害卻不小，如何有效的進行規避，在當時我進行了思考。   我想到的一點就是 Code Review，大家坐下來，一起檢查下代碼的寫法，一起判斷業務邏輯是否合理，很容易就能發現那幾個事故中的問題。   今年不定期的舉辦了 15 場 Code Review，發現了很多問題，例如邏輯錯誤、理解誤差、寫法優化等。   還有很重要的一個舉措就是推廣代碼注釋，成員們普遍對注釋比較吝嗇，你自己顯而易見的寫法，別人可能難以理解。   況且好記性不如爛筆頭，注釋也能幫助自己理解比較復雜的代碼。 ## 三、組件化   組件化其實就是創建物料庫，物料庫的有無會非常影響我們這邊的日常開發效率。   2022 年我每個雙月都會訂一個 OKR， 那就是整理 10 個組件，大家都很給力，組件在持續的增加中，并且都做了配套的 H5 演示頁面。   我們的物料庫包括業務組件、JSBridge組件、模板組件等，其中模板組件專用于后臺管理系統。   組內的小伙伴會將各類業務組件封裝（包括榜單、支付等）并配置說明文檔以及演示網頁，為了與客戶端調試 JSBridge，組員自己還新建了一張頁面專門為客戶端服務。   在我到公司的第一個月就發現后臺管理系統的研發占據著我們組大量的時間，而每次開發都會建文件、加權限、加接口等方面，尤其頁面布局占據著大頭。   之后整理發現，幾種常規的布局大概占總頁面數的 80% 以上，只有很小一部分的頁面需要專門定制，那么就能抽象出常規布局中包含的組件。   模板組件呼之欲出，經過一周多時間的調試，在組內開始推廣。在開發這套組件的時候，預留了許多回調，可根據不同場景做自定義的邏輯。   在模板組件上線后，就將頁面的開發從 3 天降低至 1 天以內，有些簡單頁面兩三個小時就能布局完成。   不僅如此，在活動頁面組件化后，各類常規活動的研發也大大提速，配合標準化后，一些常規活動只要在后臺可視化的配置就能快速上線。 ## 四、標準化   標準化是指在經濟、技術、科學和管理等社會實踐中，對重復性的事物和概念，通過制訂、發布和實施標準達到統一，以獲得最佳秩序和社會效益。   我的理解就是在制訂統一標準后，實現利益最大化。 **1）榜單標準化**   公司有一類常用的打榜活動，對其進行定制化的設計后，立竿見影的提升了工作效率。   先說說此系統的價值，當它完成后，受益方將包括設計組、Web 組、產品組、QA 組和數據分析組。 1. 設計組不用再考慮界面模塊，只需將精力集中到配色和插圖上。 2. 產品組不用再跟進此類活動，她們可以置身事外，設計做好的圖可以直接給配置人員。 3. QA 組不用再過一遍測試，她們只要查看頁面表現是否正常即可。 4. 數據分析組不用再為每個活動手動制訂報表，根據存儲的信息，可自動生成。 5. Web 組不用再投入人力去研發界面和接口了，只要頁面穩定運行，都不用修線上BUG了。   原先這么一個活動，人力時間包括 2 天開發，3 天測試，1 天產品，6 天時間，而現在可以濃縮到幾十分鐘，大大提升了生產力。   設計組雖然不會減少頁面設計的時間，但是切圖的時間絕對能少很多。   數據分析組本來創建報表也不會費時間，但是會打斷他們的工作，自動生成后，運營就完全不用找他們了。 **2）前后端分離**   上述是技術研發范疇的一次標準化，還有一次開發協作范疇的標準化，叫前后端分離。   因為歷史原因，這邊的前端會負責一些業務的后端工作，這就會出現職責邊界模糊，工作內容不清晰的問題，有時候還容易發生互相推諉的情況。   團隊成員也無法集中精力關注前端技術，為此，在一個契機發生后，強勢推進此標準，已順利的開始執行。   先在管理后臺試點，我們提供權限和操作日志的接口，這樣就能適配之前的驗簽和日志邏輯。   活動頁面的分離，也在穩步進行中，接下來就是我們出頁面，服務端出接口。 ## 五、工具化   工具主要是為我們開發自己所服務的，這些工具可以幫助我們提升工作效率。   例如 Redis 工具，為了便于查看緩存數據而制作的工具，包括查詢和刪除功能。QA 在測試活動或功能時，可以方便的觀察緩存的變化，以及測試完后不用叫我們幫忙清理數據了。   再有是腳本執行工具，為那些臨時處理數據的腳本提供一個統一入口，不用再上傳腳本到服務器中執行，只要將代碼放到執行接口中，就能完成腳本邏輯。   還有一個通用配置工具，將一些可變的常量存在數據庫中，可隨時讀寫，我們已經將活動中可配的參數（例如開始時間、結束時間等）都寫在其中，便于 QA 測試的時候修改。   為了提升管理后臺的開發效率，先后研發了后臺編輯器第一版和第二版，第一版組員接受度并不理想，第二版已經上線了兩個菜單。   開發了一款 VSCode 智能索引插件，因為框架寫法的原因，使得路由層的代碼不能自動跳轉到服務層，因此寫了插件擴展功能。   在功能上線前，可以對新功能加個開關，萬一有問題，就直接關閉新功能，粒度可以是頁面級別的。   不過前端發版不像客戶端那么困難，畢竟做開關是要成本的。灰度和 A/B 測試，在前端也可以執行。 ## 六、自動化   為了規范代碼編輯，引入了 ESLint，對冗余代碼和會存在隱患的代碼進行標注，幫助我們寫出更健壯的代碼。   將 Cypress 集成到管理后臺的項目中，就能進行 E2E 的測試了。   雖然工具很強大，可以模擬用戶的任何一個動作，但是奈何維護成本巨大，因為要寫非常多的測試用例。   而公司 QA 的重心都 APP 端，沒有多余的人力來做這種自動化測試。   還有一點就是，后臺都是公司員工使用的，大家的適應性都比較強，有點小毛小病也不會抓著不放，能用即可。   在 Node.js 代碼發布的流水線中，加入了基本的單元測試，以免服務不可用。   在單元測試中，寫一些代碼驗證服務是否連通，若無法連通就斷言失敗，從而阻止后續的構建和部署。   需要注意的是，在單元測試中不能在數據庫中增加數據，以免造成線上數據的混亂。 ## 七、頁面規范化   頁面規范化其實也是在不斷的演進中。大到整個頁面的結構，小到一張占位圖，一個彈框。   標簽欄預請求，就是在空閑時間去請求隱藏菜單欄的接口，在用戶切換時，能瞬間將隱藏部分渲染完畢。   在用戶等待時，提供合適的 loading 動畫，加載動畫就是為了彌補服務器加載過慢的問題而設計的。   一個好的加載動畫可以從兩個層次分析，第一個層次是滿足用戶心理基本需求，緩解用戶煩躁情緒，第二個層次是給予用戶驚喜感，增加用戶對產品的好感度。   有專業人士做過實驗，如果請求需要花 2m，那么有一半的人等到 8.5s 就會離開，而增加了 loading 后，離開時間會加至 20s。   骨架屏（Skeleton Screen）是一個頁面的空白版本，通過這個空白版本來傳遞一種信息，即頁面正在漸進式的加載中。   骨架屏的布局能與頁面的視覺呈現保持一致，這樣就能引導用戶的關注點聚焦到感興趣的位置。   如果有條件的話，還可以對頁面進行無障礙優化，讓特殊人群在使用該網站時，也能有很好的體驗。 ***** > 原文出處： [博客園-前端體驗優化](https://www.cnblogs.com/strick/category/2360021.html) [知乎專欄-前端性能精進](https://www.zhihu.com/column/c_1610941255021780992) 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。  推薦一款前端監控腳本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不僅能監控前端的錯誤、通信、打印等行為，還能計算各類性能參數，包括 FMP、LCP、FP 等。