在 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 組和資料分析組。
原先這麼一個活動，人力時間包括 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）是一個頁面的空白版本，通過這個空白版本來傳遞一種資訊，即頁面正在漸進式的載入中。
骨架屏的佈局能與頁面的視覺呈現保持一致，這樣就能引導使用者的關注點聚焦到感興趣的位置。
如果有條件的話，還可以對頁面進行無障礙優化，讓特殊人群在使用該網站時，也能有很好的體驗。