前端組總結

前端組

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

體系

不一樣公司對邊界的定義都不同。咱們對界線的劃分主要分爲，是否影響了用戶可交互，可操做的體驗，效率須要高（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 前端、大數據、爬蟲~~