自我介紹下，四年工作經驗，頭兩年全棧開發，后兩年專職做前端，目前已達到高級前端工程師水平，經歷過三家公司。第一家公司，電商行業，做阿里 ISV 供應商，為淘寶賣家服務，也是我第一次接觸百萬 UV 級別的產品，在第一家公司呆了兩年，由于達到技術瓶頸期，遂跳槽，第二家公司，航運物流行業，呆了六個月（工作強度對我來說，是真的高），身體不適，沒有同意轉正。目前這家，擔任項目管理和前端組長，兩個角色，目前呆了兩年，做了很多東西，把自己的一些想法跟大家聊一聊。

入職時的環境

這是一家做保險和金融行業的公司，屬于傳統行業的科技公司，有點外包的性質，當然，也有自己的 SaaS 產品，由于是傳統行業的公司，技術棧相對互聯網公司來說，稍微落后一點。我剛來的時候，上一個前端要辭職了，然后做對接工作（告訴我，有啥問題，直接搜代碼），我算是接盤俠，前任留下的屎山，其他的，大概有以下幾點：

前端組 4 個人

其中一個歸 CTO（做后端） 管，另外兩個在廣東，我入職的時候，也沒有確認，到底要不要帶人。我來的時候，就已經在了，后面我領導跟我說，要帶下他們，我當時壓根就沒有帶人的想法，也是個坑。

歷史項目有很多個，都是基于一套從 GitHub 上弄過來的項目框架

• 沒有前端工程化體系，開發周期長，開發質量差，維護困難
• 前后端混合項目，剝離前端代碼沒有剝離干凈，后端很多文件都在，不知道重不重要，前端代碼運行在服務端，每次修改一行代碼，看效果，需要拖到服務器上進行編譯，編譯大概 1-2 分鐘左右，非常痛苦。
• 完全熟悉該項目的人員已離職（技術和產品），項目交接沒有處理好。
• 業務邏輯非常混亂，沒有相關的產品流程圖，全憑記憶。
• 服務器上運行的 Node 版本非常低，到現在還是 8.x，各種低版本的庫都在，比如 Ant Design 用的 3.6.2，在項目開發中遇到穿梭框無法進行樹狀顯示(代碼一摸一樣，在高版本 3.19.2，可以顯示)。又比如還有這種 "translate.js": "git+https://github.com/MichelSimonot/translate.js.git”
• 嘗試過升級庫和卸載其他庫，各種報錯。
• 代碼缺乏注釋，一個文件幾千行，對 React，Redux 使用，欠缺理解。

• 有過一次”爆炸”，此項目如果再繼續迭代下去，隨時可能繼續”爆炸”，現在已經是在踩雷開發階段。

  在 2019 年 10 月 18 號，24：00 發生生產事故，事故表現為，操作特定頁面，瀏覽器崩潰，卡死。

  腳本執行時間非常長，后面經查，是由以下代碼引起

  actions.getAgentListByPage({
      companyId: currentAgent.companyId,
      pageIndex: 1,
      pageSize: 20000,
      searchProvince: currentAgent.province,
      searchCity: currentAgent.city
  })

頁面很多地方存在請求 **_pageSize：20000_** 的情況，該代碼是由前任前端編寫，具體為何寫出這樣的代碼，原因未知，處理方案給到后端解決，前端配合加入 `workbench` 字段，凌晨 1 點左右得到解決。

• 一套項目上，運行著兩套系統。

• 打包出來的項目代碼體積有 49.5MB，頁面首次加載耗時 11.4 min

基于以上的原因，向領導提出過重構，沒有同意，我認為可能有兩個方面的顧慮，

• 從人力資源條件來講，并不允許。
• 從公司戰略角度來講，能掙錢的項目就是好項目。但是，這并不影響我建設前端工程化體系。

項目人員能力較弱

• 測試同學報備 BUG，沒有記錄可復現步驟。
• 任務管理工具平臺沒有真正利用起來，相關項目需求，BUG 沒有整理起來放在上面。
• 產品不理解大概的技術實現，沒有把產品文檔梳理，留存下來，不理解客戶的真正需求，以至于技術實現比較雞肋。

前后端接口對接，沒有相關的文檔

產品畫的原形 和 UI 設計稿不規范

列舉了以上的這些點，爛攤子太多了，好在有一個點，領導的支持力度還不錯，看我是如何突圍的。

明確自己的任務

前端技術建設的核心目的，是為了提高開發效率，保證開發質量，為保障項目高質量按時交付，同時兼顧考慮中長期研發實際情況，結合團隊實際能力，為未來做技術儲備，為業務發展提供更多的可能性，大概將自己的分為以下四類

• 基礎架構設計，主要目的是從架構層面出發，通過流程化設計，規避常見問題，提高開發效率。
• 工程化設計，與代碼強相關，主要目的是提高代碼質量，增強代碼的長期可維護性，降低開發時間和成本。
• 團隊管理，通過合理有效的團隊管理，提高團隊人效比，為未來項目研發、技術發展，進行人才儲備、技術研發。
• 項目管理，進行合理的項目管理，合適的工時排期和迭代計劃，提高項目交付質量和效率。

如何解決

首先，要對現有的問題進行梳理歸納，按照問題的優先級進行排序，然后，分階段性目標進行實現，對于上面的問題，我大概整理了一張表格

問題	優先級	成本	目標
如何打造前端工程化體系	p0	高	提升整個前端團隊的開發效率、按時交付、保證交付質量。
如何進行團隊管理	p0	中	進行人才儲備，提高團隊人員技術能力
如何進行項目管理	p1	中	掌控全局，知道項目下的人都在做什么，資源協調

團隊管理

人員管理

• 初來乍到，首先就是跟大家一起聊聊天，了解他/她的想法，以及個人情況、技術能力、興趣愛好、性格特點等。
• 團建聚餐，經常請大家喝奶茶/咖啡，不定時的組織活動，通常是聚餐（個人出錢），為下面的工作，好開展。
• 導師幫帶，新人進來后，安排一個人帶著他，答復常見問題，由簡單的需求再到核心模塊的負責，一點一點施展壓力。
• 新人適應，負責安排新成員的發展方向，并在新人入職的前幾周，了解項目框架和開發模式，再安排其做基于現有頁面的優化，幫助其了解不同人負責的業務。
• 責任劃分，明確團隊里人員定位，并使其知曉，根據成員能力不同，態度不同，安排適合其的任務。
• 前端周會，每周一次，組織大家開前端周會，在這個會上，過下大家目前手頭上的事情，有沒有遇到什么問題，需要協調的一些資源，進度把控等。
• 技術分享，不定時的前端技術分享，主題不限，并把相關分享后的資料，上傳到前端文檔管理，方便日后的人員進行查看。

權限管理

主要是指代碼權限控制，目的是確保代碼安全，問題可控可避免可追溯

具體管理舉措有以下幾條：

• 公司倉庫，代碼屬于公司財產，對代碼進行權限隔離，啟用內網 GitLab，默認關閉所有外網訪問權限，針對每個項目，按實際需要給開發賦予指定權限。
• 提交權限，允許開發在自己倉庫下提交，但涉及到公司倉庫的合并，需要發起 PR，然后在組長進行 CR 后，才能提交到主倉庫。
• 發布權限，對于將要發布到生產環境，權限給到組長，只允許組長進行發布。

前后端接口對接

前后端開發聯調有一個嚴重問題，就是后端接口變動或者字段改動時，沒有在事前事后通知相應前端開發，測試人員，導致效率底下，并且會出現各種異常情況。

因此，通過梳理開發流程，出接口文檔，作為對接標準。

我們使用 apiDoc 來作為前后端聯調標準。

但在實際情況中，還是會有一些接口文檔和實際接口不符的情況發生，導致一些問題產生，這個我們也在思考。

前端工程化體系

剛入職的時候，由于上面的項目框架問題太多，之前也嘗試過解決，但，解決不了，領導也意識到了這點，而且也有新項目進來，就讓我重新搞一套項目框架。所以，我自研了一套基于 Webpack 的項目框架和工程化體系，做這件事的目的，就如我上面提到過的一樣，提升整個前端團隊的開發效率、按時交付、保證交付質量。

基礎架構設計

Git 分支管理規范化

我們使用的是 Git Flow 分支管理策略

Git Flow 最開始是由 Vincent Driessen 發行并廣受歡迎，這個模型是在 2010 年構思出來的，而現在距今已有 10 多年了，而 Git 本身才誕生不久。在過去的十年中，Git Flow 在許多軟件團隊中非常流行

分支命名規范

• master 分支：master 分支只有一個，名稱即為 master。GitHub 現在叫 main
• develop 分支：develop 分支只有一個，名稱即為 develop
• feature 分支：feature/<功能名>，例如：feature/login，以便其他人可以看到你的工作
• hotfix 分支：hotfix/日期，例如：hotfix/0104

分支說明

• master || main 分支：存儲正式發布的產品，master || main 分支上的產品要求隨時處于可部署狀態。master || main 分支只能通過與其他分支合并來更新內容，禁止直接在 master || main 分支進行修改。
• develop 分支：匯總開發者完成的工作成果，develop 分支上的產品可以是缺失功能模塊的半成品，但是已有的功能模塊不能是半成品。develop 分支只能通過與其他分支合并來更新內容，禁止直接在 develop 分支進行修改。
• feature 分支：當要開發新功能時，從 master 分支創建一個新的 feature 分支，并在 feature 分支上進行開發。開發完成后，需要將該 feature 分支合并到 develop 分支，最后刪除該 feature 分支。
• release 分支：當 develop 分支上的項目準備發布時，從 develop 分支上創建一個新的 release 分支，新建的 release 分支只能進行質量測試、bug 修復、文檔生成等面向發布的任務，不能再添加功能。這一系列發布任務完成后，需要將 release 分支合并到 master 分支上，并根據版本號為 master 分支添加 tag，然后將 release 分支創建以來的修改合并回 develop 分支，最后刪除 release 分支。
• hotfix 分支：當 master 分支中的產品出現需要立即修復的 bug 時，從 master 分支上創建一個新的 hotfix 分支，并在 hotfix 分支上進行 BUG 修復。修復完成后，需要將 hotfix 分支合并到 master 分支和 develop 分支，并為 master 分支添加新的版本號 tag，最后刪除 hotfix 分支。

提交信息規范

提交信息應該描述“做了什么”和“這么做的原因”，必要時還可以加上“造成的影響”，主要由 3 個部分組成：Header、Body 和 Footer。

Header
Header 部分只有 1 行，格式為<type>(<scope>): <subject>。

type 用于說明提交的類型，共有 8 個候選值：

1. feat：新功能（feature）
2. fix：問題修復
3. docs：文檔
4. style：調整格式（不影響代碼運行）
5. refactor：重構
6. test：增加測試
7. chore：構建過程或輔助工具的變動
8. revert：撤銷以前的提交
9. scope 用于說明提交的影響范圍，內容根據具體項目而定。

subject 用于概括提交內容。

Body 省略

Footer 省略

這樣做起來的好處，這個項目下：

• 對于分支，每個人在做什么，我看分支就清楚。
• 對于修改內容，看前綴就知道這個文件改動了什么。
• 對于版本迭代，看 Tag 都上線了什么內容。

總之，一目了然。

開發人員基本流程

在這個流程中，開發人員只對個人倉庫擁有可控權，無法直接改變公司倉庫代碼，當需要提交到公司倉庫下時，需要發起 PR 請求，經過組長 CR 后，將其代碼合并到公司倉庫下。

主分支代碼和線上代碼進行隔離，由組長將指定版本的 Tag 發布到生產環境，再通過運營人員直接從 GitLab 上拉取指定的 Tag，然后打包發布。

通過以上流程，前端代碼能保證高質量，高穩定性的狀態，運行在服務器端。

工程化設計

要根據實際業務情況和團隊規模，技術水平來做，關鍵是要形成一個閉環，所謂閉環就是從零開始到上線再到迭代的全鏈路，有很多節點，這些節點需要根據實際情況進行設計，避免過度設計。

定制 Webpack 項目框架

為何不是 create-react-app

create-react-app 是基于 webpack 的打包層方案，包含 build、dev、lint 等，他在打包層把體驗做到了極致，但是不包含路由，不是框架，也不支持配置。所以，如果大家想基于他修改部分配置，或者希望在打包層之外也做技術收斂時，就會遇到困難。

為何不是 umi

umi 提供的功能很多，這也導致它太過于臃腫。而且你還要去學它的封裝化配置，而不是學原生第三方庫的配置，如果你只想要一些簡單的功能，追求更高的可玩性，哪 umi 不太適合。

所以，我自己定制了一套腳手架，實現了以下功能：

• 快速上手，只要了解 React、Mobx、Webpack 和 React Router，就可以快速搭建中后臺管理平臺
• 路由系統，基于 react-router 實現的路由系統
• Loading，不需要重復寫組件 Loading 判斷
• 國際化，基于 react-intl-universal 實現的國際化
• 網絡請求，基于 axios 實現的請求攔截
• 頁面交互，基于 mobx 實現的數據交互方式
• UI，使用業界最著名的 ant-design
• 代碼規范校驗，使用 eslint、pre-commit、lint-staged、prettier、stylelint
• 模擬請求數據，基于 mockjs 實現
• 打包工具，目前最流行的 Webpack

解決了以下的問題：

• 約束開發人員代碼規范
• 方便提供給其他開發使用標準的腳手架，并提供技術支持

完成整個編碼過程的一個閉環：

• 編碼前：編碼規范，最佳實踐
• 編碼中：自研項目框架、代碼校驗
• 編碼后：發布部署工具 JenKins，手動發布或 CI/CD

這些節點要視實際情況，以最小成本去做，然后逐步升級。比如編碼規范，我們是采用業界比較著名的 Airbnb JavaScript 代碼規范，搭配eslint、pre-commit、lint-staged、prettier、stylelint 去進行約束。

這套項目框架，目前開發體驗非常爽，在我司多個產品線上，投入使用，并已開源，框架地址，演示頁面比較少，大佬們覺得不錯的話，可以給個 Star ??，也歡迎給項目提 issues ～

業務場景

我們是做 ToB 業務，存在頁面上大量使用表單的場景，所以，把我們的表單頁面做成可配置化，實現了大部分頁面表單配置化，減少前端人力資源投入。

針對公司的實際業務場景，其他子系統不會特別復雜，頁面也不會多，共享一套賬號體系，這里采用的思路是只有一個項目，不分主從系統，通過 Webpack 配置多頁面，不同的子系統進入的首頁內容不一樣，加載內容不一樣，菜單導航，則通過后端對每個租戶進行區分，來做到租戶看到的菜單系統不一樣。

如果子系統特別復雜，有主從系統概念，可以考慮使用微服務設計，這里不做過多介紹。

靜態資源

除了業務代碼以外，前端還會有一些公共靜態資源，例如 React 資源，Ant Design 資源，BizCharts 資源，以及一些圖片文件等。

對于這些文件，是所有項目所共享的，假如這些文件分散在各個項目里，既沒必要，也容易導致不同項目依賴文件不統一。

我們是放在 S3 上，做 CDN 靜態資源加速，然后前端項目通過引入url 來使用這些資源，這樣可以減輕自己的服務器網絡帶寬消耗。

項目管理

• 任務分配，產品把相關的需求，經過討論，可行性分析，通過項目管理工具，放到迭代計劃中，錄入開發工時，測試工時。
• 文檔管理，采用項目管理工具自帶的文檔，要求做到文檔可以團隊編輯，可以查看到編輯歷史。
• 項目周會，過大家手上目前的迭代進度，遇到的問題，需要協調的資源，風險控制等。
• 項目復盤，復盤首先是要做的是事實陳述，開始診斷、分析存在差異的原因，找出導致成功或失敗的根本原因后進行規律總結。明白為什么會成功、哪些關鍵行為起了作用，這些行為有沒有適用條件，對于提高后續行動的成功率有沒有價值。

熟悉產品線業務

所謂技術服務業務，找產品了解現有的業務流程以及痛點，甚至未來要做的一些產品規劃，好的技術架構，要考慮各種各樣的業務場景，怎樣才能結合業務的復雜度，設計出顆粒度更加細化的組件。

畫出產品架構圖

提升相關人員的能力

產品人員

需求頻繁且混亂，決策搖擺不定、動輒推倒重來。市面上一個好的產品經理是很貴的，沒個三四萬是拿不下一個真正靠譜的能抗住復雜產品線的產品經理，但是很多公司老板是不愿意花這個錢，一般就會招個工作一兩年的產品經理先過來，頂個位置把這個工具給做出來就行了。恰恰因為這樣一個認知導致產品經理這一層他既沒話語權，又不能讓自己閑著，所以層出不窮的需求全堆上來了，而對于公司長久型的產品架構就把控不住，如果一個產品經理無法起到，上對客戶負責，下對開發負責，不會對所有需求進行篩選，把需求只會丟給開發，不會進行工時把控和質量把控。甚至對現有產品有什么功能，都不了解，那么就不是一個合格的產品。

所以對產品經理的要求非常嚴格，因為一個公司，如果戰略方向把握住了，那么核心是要看產品，能否把握住市場方向，非常關鍵。這樣才能決定你是否能占有市場，由于我司是做一個 ToB SaaS 化的平臺，所以，必須要求產品經理清楚的了解客戶實際需求，需求背后的實際場景，提煉出來哪些是共性的需求，哪些是客戶定制化的需求，然后再討論，再進行落地實際的開發。

測試人員

對測試人員，盡量覆蓋全所有場景，保證核心流程暢通，要求能找到復現步驟，提高開發解決 BUG 的效率。

設計規范

由于我司采用的是 Ant Design UI 庫，所以設計標準，盡量都是按照 Ant Design 現成組件和樣式來做，避免開發二次修改，參考這個鏈接 Ant Design 設計原則

某個列表頁

普通的列表，和設計，產品都約定好，上面是篩選，下面是按鈕，底部是表格展示。

某個詳情頁

詳情頁大量會使用到表單，所以直接使用 Ant Design 的 From 表單組件。

表單每行放多少個，都是以 Ant Design 組件來的。

這樣帶來的好處就是盡量避免定制化的開發，所有列表和詳情都是按照這種風格來進行開發。

執行成果

開發效率

組內人員開發效率，較之前提升了一倍左右，普通的列表頁面（搜索、展示、彈窗 ），包含接口聯調 + 自測，大概 1 天左右完成，詳情頁面，復雜一點的表單交互，表單組件聯動，大概在 2 天左右完成，包含接口聯調 + 自測，目前我們也在探索 Vite，Snowpack，極大的提升開發體驗。

系統情況

SaaS 系統，首次無緩存加載耗時 3.22s ，三個系統（ 30 多個頁面，14 個公用組件）打包出來的體積在 9.3MB

當然還有優化空間

設計規范

目前大部分頁面不需要設計資源投入，盡量按照 Ant Design 設計標準和我們自定的 UI 標準風格來做，減少設計人員的工作投入。

項目文檔

目前所有的產品文檔，技術文檔都非常規范，可以溯源，以及當時在什么樣的場景下，為什么要做出這樣的解決方案。

總結

上面這些，包含其他的，大概花了一年多的時間，建設完成，我們目前的基建狀況如下表所示

如果你覺得對你有幫助或啟發，歡迎點贊留言。