前端組總結

劉卿發表於2018-02-06
前端

前端組

其實在內部我們叫大前端，公司名也不報了，媽媽說要低調，嗯嗯！

體系

不同公司對邊界的定義都不一樣。我們對界線的劃分主要分為，是否影響了使用者可互動，可操作的體驗，效率需要高（ps：窮！）

在我們這面對前端的定義是高效率的實現可互動並且高質量的產品。所以我們整體的支撐體系如下：

  • 應用
  • 規範
  • 工具
  • 團隊

應用

最終前端這塊主要負責前端開發（本職工作）和服務端開發（應用邏輯）。

為了保證服務的高可用，並且能提供靠譜的使用者體驗，在整個應用這塊我們主要做了4件事：

體驗。

體驗這塊主要和設計團隊的溝通比較多。設計團隊主要負責：視覺規範、互動規範、介面設計。前端團隊主要負責：元件抽象、視覺還原、互動還原 。

元件化這塊，我們調研了多種方案（其實業內成熟方案真的很多）最終結合各種調研以及我們自己的業務場景我們得到以下結論：

  1. 我們是資料展示為主的業務，所以要根據資料模型來對元件進行建模
  2. 高內聚，解決檔案管理的問題，可以快速剝離和替換
  3. api統一
  4. 可獨立執行
  5. 業務一致性

基於以上的結論，我們先封裝了第一批元件，但是發現整體粒度還是比較粗，UI一致性很難保證，所以我們在這一層的基礎上抽離了一層UI元件，用來保障UI的一致性。

名稱空間是通過資料夾的方式去管理，每個元件通過index.js來做為出入口。

每個元件內部存在於一個狀態組，來對內部邏輯進行控制。

前後端分離

前後端分離分為2塊，由於我們的業務資料量比較大，單個介面的速度會非常慢，如果採用後端直出的方案去渲染頁面的話，頁面白屏的時間會非常長。所以我們採用前端spa，後端自建服務（基於Node.js)。

  • spa

    • 框架選擇這塊我主要針對幾個方面進行調研，社群、是否資料驅動，是否大廠出品，是否支援ie8（或者通過改造可以比較容易適配），團隊整體的學習和上手成本（部分同學比較弱），圈定出來的範圍其實比較明顯angular1.x，react，團隊同學一致對大而全的框架比較感興趣，react在構建大型應用上需要引入太多第三方的包來管理狀態，所以最終的決定是angular1.4.7（改動的成本最小）

    • vue是團隊內部比較喜歡的框架（不相容ie8/(ㄒoㄒ)/~~），所以我們在移動中嘗試使用，相比於react的jsx，我們更加喜歡vue的簡潔

    • 在pc端我們的產品是非常重的資料型產品，所以前端的單個檔案會比較大，通過構建工具合併後檔案會非常大。所以我們引入了code split的方式，通過路由來切分檔案，並且在會在主頁面渲染完成後，預載入部分指令碼（js、css我們是壓縮在一個檔案中的），來優化整體的體驗。

  • 服務端

    • 服務主要以Node.js為主，部分老系統有python，也有php，為什麼要選Node.js呢？
      1. 團隊整體為前端團隊，整體技術棧以js為主，python和php的同學只有1-2個
      2. 業務相對沒有那麼複雜，前後端的一部分邏輯是可以共用的
      3. 框架經過封裝後上手難度相對較低
      4. 大家對這塊的熱情比較高
      5. 單方向溝通相對更輕鬆，效率也更快，ps：主要薪資更高了
    • 業務分2塊
      1. 主要負責公司2條產品線的應用研發工作
      2. 自研類的產品（微信預警、微信日報、郵件服務、內部專案管理平臺搭建、前端監控埋點等）

監控

監控這塊分了3部分：

  • 前端監控

    • 由於我們的主要客戶是酒店，遇到問題後，他們內部在遠端除錯上很難辦到，但是有時候會出現使用者有問題，我們自己通過賬號去復現就很難發現問題，根據上面的情況，我們實現了一套前端監控的體系，用來捕獲使用者的操作路徑和js層面的異常。

    • 主要實現了2部分功能：

      1. 操作路徑捕獲，每個使用者進來後記錄使用者的每次點選，根據時間和元素，來判斷使用者的操作流程。
      2. 捕獲window.error和劫持ng和vue中的handleerror方法

  • 服務監控

    • 程式和硬體層面的監控比較簡陋
      1. 程式守護pm2
      2. 埠掃描
      3. CPU、記憶體、硬碟監控 上面的產生異常後，呼叫預警服務傳送到對應的使用者
    • 在業務程式碼中部署特殊的埋點，來監控某些特殊的場景

  • 預警

    • 中介軟體服務，目前只實現了2部分：
      1. 微信預警
      2. 郵件預警

    通過api來接收使用方的預警資訊，目前也用在給客戶傳送相應的報表

工程

工程方面，在專案的評審，開發，聯調，測試，上線，運營各個環節，我們提供相應的工具支援，以及標準操作流程和文件，從而保證各個環節的產出質量和效率，以及各個環節之間過渡的平滑性。

  • 評審。包含需求評審、設計評審、測試評審。
  • 開發。包含風格校驗、前端除錯、服務端除錯。
  • 聯調。根據api自動生成mock資料。
  • 測試。提供程式碼編譯、部署，以及模擬環境的模擬（灰度）。
  • 上線。同上

規範

規範化主要是eslint、csslint這類工具保證程式碼的風格，結合我們的團隊特性我們也產出了自己的程式碼規範（每個團隊應該不一樣，所以不獻醜了）。 整體質量的保證是各個組的leader，會定期review專案的程式碼（主要是忙，2週一次迭代，只能抽時間做）。

工具

框架都是通過業內比較熟知的框架來封裝的（前端angular，後端express），

  • 前端主要是實現了名稱空間控制，路由控制、根據路由對檔案進行codesplit，資源預載入，通用介面和方法封裝。
  • 後端基於express自研，api簡化，增加路由自動生成，資料庫分庫分表支援，多人協作，埠自動分配，nginx配置生成，業務分層處理等功能

自動化工具除了大家常規的工具如壓縮、合併這類的，基於我們的專案我們自研了專案自動構建，配置自動構建等

團隊

  • 分享

    • 團隊內部
      • 每週一次分享會，分享人自己定主題，分享人是通過輪詢的方式來定。
      • 分享的內容可以是專案心得，也可以是個人情感，也可以是新技術等等（一點節操都沒有啥都不限制）
    • 公司層面
      • 跨事業部組織公司層面的分享會，效果還不錯，借用了FEDAY的名字（嘻嘻），還有自己的logo衫，當然要感謝老闆的支援，以及小夥伴們的熱情。

  • 調研/自研

    • 大家都是靠自驅動去造輪子或者研究開發新的玩意兒
    • 最近在關注的新技術
      1. 看graphql，感覺在api這塊是下一個爆點，準備在下一個專案中引入。
      2. 據說app的專案要回到我們手裡了，最近在看RN，當然也在學一點OC和JAVA
      3. 其他的也會了解一點兒，但是看場景吧，可能過幾天就忘了。。

  • 總結

    • 專案。每個專案結束，參與人會分享下當前專案的心得。
    • 年終。每年每人回顧下上一年的得失。

ps：招人啦？liuqing@liluo.me 前端、大資料、爬蟲~~

相關文章