點我達三年前端路暨點我達前端演變過程

前言

2016年8月份，我開始了人生第一份前端工做。直到今天，快滿三年，愈發有些東西不吐不快。三年的前端變化很快，感受應該從新認清未來的方向，整理整理三年工做所得，爲下一個三年謀定然後動。在點我達三年的前端生涯，同時也是點我達前端架構演變的三年，本身親身經歷了這些變化，能夠說是很是幸運的。本身從一個前端菜鳥成長成可以獨立負責並帶領網關團隊的前端老鳥，對一個創業公司如何從零基礎的前端生態演變到一個比較完整的前端生態有了清楚的認識。同時也在這個演變過程當中發現不少問題，這些問題必然會一直存在，直到完全解決。

本文以點我達前端演變的過程爲主線，附帶說起一些想要說的感覺。

本文同步發表在：豆米的博客

一、點我達前端三年演變進程

上圖簡單地描述了演變的一些重要節點，從最開始的先後端緊密耦合到第一次應用nodejs，後面引入微服務化後，前端承擔起網關的開發與維護，無時不刻在提醒咱們：前端可以勝任的工做會愈來愈多~

接下來詳細說說每一個演變過程

1.一、原始混沌狀態(2016年)

初到公司(2016年中旬)，彼時的前端頁面是和java一塊兒打包發佈的，不管是開發仍是發佈，都透露着一種「生死都要在一塊兒」的感受，因而咱們緊隨時代潮流，開始了大刀闊斧的改革，引進Nodejs。

1.二、初嘗Nodejs(2016年末)

彼時(2016年末)對於Nodejs沒有太多的深刻，只是拿公司官網初試牛刀。涉及到的後臺數據都是在Nodejs層使用http去java端請求。這個時候開發和發佈第一次和服務端解耦，第一次感受到了「分開，對彼此都是個好事」是句真話。前端沒有太多束縛，而且還能接觸到一些運維上的事情，何樂而不爲呢？

1.三、開始大規模應用Nodejs(2017年初)

初嘗Nodejs發現開發提高的效率仍是很明顯的，因而開始在全部的新項目中使用Nodejs，全部的中臺系統開始使用Nodejs做爲網關，這個時候網關BFF的概念開始出如今咱們的工做中。雖然開發效率是提升了，可是先後端在開發協做上仍是暴露出不少問題。畢竟使用http接口，網關層是沒法感知到java端接口的變化。可是這個問題在隨着公司的總體架構變遷而隨之被解決掉。

1.四、全面引入微服務，開始使用dubbo協議(2017年中旬)

引入微服務(2017年初)是一項巨大的工程，全部的java項目都須要改造，前端網關也不例外。前端網關除了須要有一個dubbo客戶端以外，還須要解決上述階段遇到的協做問題，因而解析javadoc成了後面全部項目的必通過程。在後面的演變過程，咱們能夠全自動地下載並解析javadoc文檔成js或者ts語法格式文件，尤爲使用ts以後，全部的方法、參數均可以所有自動提示，可謂是解放了一大批生產力。

1.五、傳統的express網關遭棄用，轉而開始使用容器理念和AOP模型(2018年初)

在傳統的express網關模型中，發現了不少弊端(畢竟經驗不足)，js弱類型、代碼結構不合理，冗餘代碼太多，業務和框架沒有解耦等等。因而咱們開始改造，使用inversify來製造容器，使用AOP來簡化全部中間流程，剩餘給開發的就是純業務擴展。在這套全新的網關框架下，咱們所有使用typescript，藉助ts語言的強類型特性，咱們作了不少之前很差作或者作不到的事情，好比api文檔的自動化，好比先後端類型的統一化等等。

1.六、網關生態以及前端開發流程再優化(整個2018年)

生命奔騰不止，折騰便不止。在當前nodejs大量應用的狀況下，維護可持續的生態便成了重中之重。因而咱們不斷在開發業務的同時，不斷加固咱們的地基。從服務器性能監控到服務器告警日誌監控，再到業務數據圖表展現，用戶行爲跟蹤(未作)，無不體現咱們想要作好前端網關這一層的決心。

1.七、高併發的挑戰-長鏈接網關(2018年末)

終於咱們仍是順應了歷史潮流，在2018年中旬的大量測試以後，開始引入了長鏈接網關，挑戰同時10萬騎手在線的壓力。歷史證實了，咱們僅僅用了四臺常規的服務器就抗住了來自rocketMq 多達400QPS的消息處理以及線上10萬騎手在線的壓力，固然得益於nodejs優秀的併發性能，同時咱們藉助redis解決了不少當時遇到的問題。

1.八、將來可期

將來，咱們指望在網關生態上作更多的建設，當前在作的即是引入Kong來解決項目龐大的問題，另外還有更多待解決的問題須要咱們繼續折騰~

二、點我達網關生態

前端在服務器端的生態圈不如java那麼齊全，不少東西也都是在摸索。通過了這麼幾年的打磨，多少對網關這個東西有必定的總體模型，下面的示意圖即是當前點我達網關生態的模型，是當前在作以及將來要作的事情

下圖是一張寬泛的網關架構圖：

在當前實現的版本中，詳細的生態應該是這樣的，不只有可持續發展的業務能力，也具有穩定高效地地基，同時能夠提供衆多能力給開發的童鞋：

三、點我達網關開發流程

話說技術的積累離不開業務的拓展，沒有實際項目的實戰，一切都是紙上談兵。因此有一套完善的開發流程不只能夠改善開發體驗，並且能夠保障項目的質量。這幾年的實戰下來，爲了達到上述的兩個目的，咱們不斷優化開發流程，從此仍然會不斷優化。下圖即是技術開發整個流程，僅供參考：

而技術開發流程離不開各類各樣的評審，好比上述中的代碼評審，從PM的角度來闡述這個流程多是這樣的：

四、移動端技術棧

這裏的移動端包括了移動端Hybrid H5和網關，這條技術棧包含了主要的技能點，每一個技能點都有對應的知識庫在內部分享。裏面的技術棧也會隨着業務的演變和迭代進行微調。雖說大部分是網關開發，可是咱們也承擔移動端H5頁面的開發，目前點我達騎手端和商家端，仍然嵌入很多的H5頁面。有興趣的童鞋能夠自行下載體驗一番(如何區分是H5頁面仍是非H5頁面，這裏就不用說了吧？)

五、團隊管理

這是我第一次談及團隊管理。以前沒有太多的經驗，可是隨着從2018年初開始負責移動端網關以後，我本身就常常反思，如何負責好移動端網關？雖然沒有明確的title，可是本身的思想發生了很大的轉變，作需求再也不是單純作需求了，會考慮需求的合理性，需求與同時期需求的關聯與衝突。每次需求排期，都要考慮好需求適合開發的人選，以及如何管理你們的任務？遇到大的項目，考慮的東西更多，什麼兼容性、發佈流程、技術方案選擇，都會和開發人員討論一番並在即將上線前再檢查一遍。

有的人可能會說，這不是事無鉅細地忙活嗎？那還有時間開發嗎？其實這些東西由於有了一套完善的開發流程，不少事情在流程上都被解決掉了，並不會花太多時間。技術畢竟仍是個人第一選擇，在職的兩年多，除了關注這些以外，還會和你們一塊兒發現問題，一塊兒解決問題，一塊兒造輪子。咱們從無到有，不斷給前端開發添磚加瓦~

5.一、分析團隊以及當前開發遇到的問題

由於不是憑空進入這個團隊，因此對於團隊成員和團隊項目有着不少了解，這對於我來講是幸運的？而後除了分析你們的技能點以外，就是尋找影響你們開發體驗的一些問題，因而有了這麼一張圖：

每過一個季度，咱們都會將這個季度遇到的問題再次從新更新一遍，哪些解決了？哪些解決了可是還不夠完善？哪些是新增的問題？以此給你們一個」人人爲我，我爲人人「的積極心態。讓你們彼此知道咱們團隊的發展狀況，有一種主人翁的意識去工做。通過一年多的改進，變化仍是很明顯的：

5.二、輸出統一的目標

在負責網關以後，創建的釘釘羣裏，公告上我就提出了團隊的核心目標是「打造質量可靠、開發速效的前端網關團隊」，而咱們一直追求的也是這樣的一個節奏。沒有可靠的質量保證，一切皆惘然。因此咱們在開發流程中植入了不少環節去保證這個目標能夠有條不紊地實現，好比加入技術方案評審，在項目初期排除有風險的問題點，在分支測試環節，進行代碼review，檢查代碼規範以及邏輯是否有問題，在灰測階段，使用A/B測試來檢查項目是否有別的問題，層層保障只爲了每一個需求均可以交付一份滿意的答卷。

保障質量的同時，咱們也但願可以提升開發效率，可以機器完成的事情毫不要人爲去作。包括一些檢查，自動化測試等等，有了這些自動化行爲，咱們才能體會到開發的絲滑順柔，纔能有時間去作些咱們本身想作的事情，而不只僅是業務。

如此兩者正向循環，互補互惠，能夠給團隊帶來極大的能量。

5.三、規範化開發流程

規範化開發流程是指從拿到需求到需求上線，這個流程在上面的圖已經表達過了。曾經就有故障由於流程的某個環節缺失，致使bug直接反饋在線上，因此保證規範化開發流程是頗有必要的。

5.四、輸出並維護團隊共有的知識庫

自從全組推行使用Notion軟件以後，團隊的協做變得更加順暢。在Notion上咱們單獨開闢出一個專欄，叫作「前端知識庫」，上面能夠放置你寫的博客，也能夠引用你看過的某篇很是有意思的文章，並造成分類，這些知識庫也是對現有技術棧的學習。除了這些，咱們還會將各類前端規範、入門手冊、項目介紹等等信息都維護在這裏，不只方便團隊成員查閱，更能夠幫助新成員快速融入團隊並上手項目。如圖所示：

5.五、鼓勵團隊技術與業務創新

除了正常的業務迭代需求，內部時常會有一些新的系統須要開發。在新項目開發上，鼓勵你們使用最新技術，好比小程序的使用、GraphQL的使用等等。而那些正常迭代的項目，也能夠對某些模塊進行升級，不斷優化。在業務上，能夠有造成本身的領域模型，幫助產品更好地規劃需求的重構等等。團隊畢竟不是獨立存在的，咱們須要協做的第三方不少，有了本身的一套新技術基礎，咱們才能夠在面對需求的時候，抉擇最佳的方案。

5.六、按期鞭策團隊

前端知識變化太快，標準一年一次迭代。因此咱們爲了更快成長，須要不斷地更新舊有和新加的知識，因而咱們按期組織你們進行考試。是的，你沒聽錯，就是像學生時代那樣的考試。每一個人能夠從各個渠道上搜羅題目，而後造成一份綜合性試卷，這些題目要求和現有技術棧緊密貼近，能夠很基礎，也能夠很開放。每次考試題目都會維護起來並分門別類，給你們有空的時候翻翻看。每次會議的時候，我都會這麼跟你們說這樣的一句話「未來萬一你真的想離開團隊去尋找更好的平臺，這些知識或許能夠幫助你面試經過，而不用去瘋狂刷題背題，由於咱們天天都在面試」。

六、最後

好了，閒扯了這麼多，最後歡迎關注個人我的博客：豆米的博客