我是如何突圍傳統行業的？

背景

自我介紹下，四年工做經驗，頭兩年全棧開發，後兩年專職作前端，目前已達到高級前端工程師水平，經歷過三家公司。第一家公司，電商行業，作阿里 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 標準風格來作，減小設計人員的工做投入。

項目文檔

目前全部的產品文檔，技術文檔都很是規範，能夠溯源，以及當時在什麼樣的場景下，爲何要作出這樣的解決方案。

總結

上面這些，包含其餘的，大概花了一年多的時間，建設完成，咱們目前的基建情況以下表所示

若是你以爲對你有幫助或啓發，歡迎點贊留言。