在 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 組和數據分析組。
- 設計組不用再考慮界面模塊，只需將精力集中到配色和插圖上。
- 產品組不用再跟進此類活動，她們可以置身事外，設計做好的圖可以直接給配置人員。
- QA 組不用再過一遍測試，她們只要查看頁面表現是否正常即可。
- 數據分析組不用再爲每個活動手動制訂報表，根據存儲的信息，可自動生成。
- 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）是一個頁面的空白版本，通過這個空白版本來傳遞一種信息，即頁面正在漸進式的加載中。
骨架屏的佈局能與頁面的視覺呈現保持一致，這樣就能引導用戶的關注點聚焦到感興趣的位置。
如果有條件的話，還可以對頁面進行無障礙優化，讓特殊人羣在使用該網站時，也能有很好的體驗。