【前端技術分享】前端技術改造踩坑心得分享

掌門教育前端技術分享會第一期已於1.23號落幕，如下爲大咖講師們現場演講的整理稿，感謝你們的支持：

講師介紹

程波，前端技術架構師，來自掌門教育業務系統團隊

如下爲程波同窗精彩演講的部份內容：

大前端時代，前端技術架構設計

我最開始工做的時候，加入的部門是UED團隊，整個團隊接近30號人，其中絕大部分同窗是作交互、頁面設計的，寫代碼的同窗只有10個左右；咱們這10我的裏，只有2個是寫JS代碼的，其它人都是寫HTML、CSS的；工做流程方面，我把設計稿轉化爲HTML、CSS代碼後，交給JS開發同窗，幫咱們添加彈框、banner輪播等等交互特效，打包成zip包發給PHP團隊，以後全部的業務數據集成、部署、監控等等都跟咱們沒有關係；

爲何之前的工做內容這麼侷限、狹窄？我簡單猜想一下，大概以下幾點：

1. 電子設備不普及，絕大多數人一天裏面也碰不到幾回電腦、筆記本
2. 當時上午是一件很貴的事情，網速又很慢，體驗很是差
3. 社會互聯網文化氛圍幾乎沒有，大數據、可視化、信息化等等，這些咱們如今認爲企業必備的概念，那個時候一片空白
   總而言之，前端開發缺失具體的業務實現場景

如今，徹底不同，是前端業務場景百花齊放的時代，我以前有一次去商場吃飯，在自動扶梯旁看到有一個立式樓層指示牌，我就上去滑動屏幕，想看看4樓有什麼門店，劃了二、3秒，屏幕都沒動，我當時很是奇怪，以爲屏幕是否是壞了，後來才發現這個屏幕就是固定的，鬧了一個笑話；

後來，我就思考，爲何我會以爲屏幕不動，就是屏幕壞了？答案其實很簡單，由於我以爲任何我能看到亮的屏幕，它就應該能被交互纔對；

因此，如今是前端的美好時代，由於咱們的業務場景很是很是多！

大前端時代，咱們對前端技術架構的要求更高

一我的作項目，跟100我的作項目，團隊對工程化的要求確定是不同的；作一個項目，跟同時作100個需求，團隊對自動化的要求確定也是不同的；之前咱們前端產出的產品只有百來我的、幾千人、幾萬人用，如今咱們前端項目上線，可能會面臨幾百億、上千億、上萬億的流量，這對咱們的監控、預警等等也提出來更高的要求；這樣的種種要求還有不少

也由於以上種種緣由，在這個時代，團隊、公司對於前端工程師的要求，也不只僅是會寫H5頁面、作交互就OK了；如今前端涉及的領域愈來愈廣，對開發人員的素質能力要求也愈來愈高，這是一個更多場景賦能，動力、壓力並存的時代

咱們前端的技術架構設計圖

這張圖越往上越靠近業務，越往下越靠近支撐，右側則是對整個生命週期的監控，我着重描述一下【環境管理】、【集羣管理】、【監控管理】：

環境管理：之前咱們團隊作過一個微信公衆號的需求，公衆號開發流程你們或多或少都有所瞭解，微信給咱們一個key、secret，咱們拿這兩個字段去換token，而後緩存下來，業務場景裏面，咱們帶上token去拿用戶的信息數據；當時咱們團隊只有一個測試微信號，可是有不少套測試環境，每一套測試環境都是互斥、隔離的，但在微信這種場景下，當A、B測試同窗同時作測試的時候，就會形成token反覆申請，服務請求互踢，最終致使資源耗盡，這種體驗就很是差，相似的場景還有不少，好比redis、DB等等，這就是環境管理的問題

集羣管理：201五、16年的時候，咱們作過一個整點秒殺的需求，天天中午12點、晚上19點作活動，時間只持續半個小時，當時阿里雲尚未提供快速擴容、快速釋放功能，說人話就是，12:00借100臺機器，12:30還，抱歉不支持；而咱們的後端由於種種緣由，也不太好作秒殺需求，後來我跟我老闆說，前端來實現這個功能，咱們開發完提交測試，測試也經過了，功能沒有任何問題，而後咱們的運維開發同窗過來跟我說，咱們秒殺場景大概20W左右的QPS，前端須要報備多少臺ECS？當時我就懵了，由於我當時對服務器負載一點概念都沒有，後來咱們緊急作了壓測，大概須要大十幾臺4C8G的ECS，這就一個集羣管理的問題

監控管理：去年11月份的時候，咱們的產品經理跟咱們提了一個購物車的需求，當時是PC、移動端兩版實現，工做量仍是很是大的，而後咱們開發小夥伴過來找我，問我能不能跟產品溝通一下，不作IE的支持，我跟小夥伴說沒有問題，後來我找咱們的運維同窗，問他能不能幫我拉一下生產的流量數據，數據拿到後，咱們看了一下，移動端大概95%的流量，PC端5%左右，並且PC端幾乎沒有來自IE的流量，我把數據整理了一下，發給產品，表態咱們不作IE的支持，這就很是有理有據

爲何咱們要作技改

咱們團隊如今手上的項目，有一些已經有3-5年的歷史了，實際上是很是很差作技術改造的，爲何咱們要立專項作技改呢？我問了本身幾個問題

1. 咱們如今的一些項目，變量config、接口請求代理、開發依賴、運行時依賴等等風格迥異，若是項目緊急，多人協做開發，經過看歷史備註，咱們可否實現非干係開發同窗無縫、快速上手開發？
2. 對比前面咱們設計的前端技術架構圖，若是咱們在最前置應用層部分項目，不作集中性改造，將來環境變量管理、ECS集羣管理、監控這一塊，隱性成本是否可控？
3. 若是這些項目的技術改造，不立專項作，放在業務需求裏面作，是否可行？
4. 咱們能不能容忍團隊技術落後？

這幾個問題一出來，咱們就以爲確定是要立專項作技術改造了

技術改造踩坑

踩坑一：想法太多，技術改造步子邁太大，Hold不住！

一開始，咱們作的技術改造範圍很大，開發花了很長時間進去作優化，提測後，測試同窗也發不少的樣式bug回來，由於歷史業務細節太多了，全量作風險實在過高，最後咱們沒有辦法，把這一部分的代碼都回歸了；第二個項目技改的時候，咱們就給本身定下來MVP原則（最小价值實現），圍繞咱們前面的技術架構設計圖，設計標準目標，而後只作這構建、環境管理、api代理、依賴庫統一等等幾個目標的實現，其它問題，咱們適當放到業務需求裏面去作

踩坑二：爲了技改而技改，項目技改完成，人力也浪費了

咱們中間有一個項目作技術改造的時候，測試資源很是緊張，提測後，幾乎就是壓着先後兩個需求發佈計劃來作迴歸驗證的，後來這個項目成功上線，可是尷尬的是，此後這個項目就沒有大的需求過來，前段時間我去看了一下這個項目的發版記錄，技改後只有一個優化需求上線；這就是咱們在作技術改造前，項目背景、業務需求緊急度，開發頻次等等調研不夠細緻形成的

關聯方溝通不到位，不關注業務價值，沒人驗收

在作技改方案設計的時候，我其實還挺以爲咱們方案顆粒度作得真好，業務、開發、驗收方各司其職，結果就踩了一個大坑，咱們財務系統技改發佈的時候，測試已經跑通UAT環境，代碼也合到了master分支裏面，咱們急急忙忙把產品同窗拉到咱們的技改羣裏面，但願他作驗收，產品同窗表示：如今這個點上，他不作驗收；我過去跟咱們產品同窗溝通，但願說服他作驗收，聊下來，我發現咱們產品同窗是對的，由於12月份是咱們公司的銷售大月，而已由於是年末，這是一個超級大月，提早半個月上或者晚半個月上都沒問題，但這個點上確實風險比較大；後來這個項目的技改延期了20+天，中間又由於一部分業務需求的迭代，出現了部分代碼衝突，實際上，咱們算下來，形成了4人天左右資源浪費；技改一方面是爲了知足咱們前端技術團隊本身的需求，同時，業務需求、業務保障更是咱們最重要、最核心價值之一

技術改造，不止於技術

10月中下旬，咱們剛開始作技改方案的時候，咱們一直在想，要不要上webpack五、甚至開玩笑上Vue3.0等等，此次技改怎麼樣纔可以體現咱們技術的高大上，另一方面，咱們又常常吐槽過去這些項目的技術設計作得很差

但後來，我仔細思考了一番，我發現這種認知偏見是不太準確的，這裏有一個倖存者誤差，咱們部門過去這幾年，作過的項目確定不止咱們如今技改的七、8個項目的，甚至咱們吐槽最多的老項目，其實也只佔咱們技更名額的3-4個，咱們如今團隊有50+項目，歷史項目只會更多，其它項目哪裏去了呢？由於沒有需求迭代了，或者業務被下掉了，全部不少業務代碼是跟着公司階段性目標，定製化實現的，好像問題也不大

我另一個非技術性的思考是，技術改造是一個將會反覆持續的過程，隨着業務迭代、技術演化、時間不斷前進，再過3年、5年，特別是前端領域，技術改造又會是一個輪迴；因此咱們此次的技改實現，關注底層支撐，好比環境變量規範、api請求規範、構建規範、依賴庫規範、流量灰度，日誌監控等等

咱們常常形容技術改造，是在火箭行進過程當中換零件，換零件確實是一件藝高人膽大的活，但它的前提條件是火箭至少還能飛、還能被改造，這裏其實就要求火箭自己的質量自己要過硬才行，因此這一次技術改造，咱們很是關注支撐這一層，也就是這個緣由

感謝閱讀，更多精彩內容，歡迎關注咱們掌門教育前端技術