半年工做總結

一 先後端溝通

    先後端溝通是一個老生常談的問題。先後端分離的同時就必然會存在這樣的問題。   首先來看一下咱們的場景：

1.前端本地開發須要鏈接測試服務器，而且要作token驗證（這個其實能夠省略，但並無），以致於每次都要從數據庫手動查一下token。

2.先後端須要聯調，那麼就要鏈接後端開發的電腦。頻繁的切換開發和測試，以致於和不一樣的開發合做，須要配置不一樣的配置。

3.存在跨域問題。  目前經過本地啓動nginx 以及更改host文件實現。  至關心酸，瀏覽器host有緩存切換host是個噩夢，還要莫名啓動ngxin，我總感受怪怪的。

4. 有時候重構代碼，接口請求參數不當心改了，本地測試沒問題，只有放到uat或者生產纔看出問題。

5. 後端把接口格式改了，須要即時通知你更改請求參數。

6. 數據不足，不能測試。

。。。。。。

總之，很是麻煩，誰經歷誰知道。因此我作了一箇中間mock服務器，前端不須要向後端要數據了。mock服務器會按照約定的格式生成數據，同時作了一個接口服務器，用來展現項目中全部的接口。 而且接口發生變化會自動通知mock服務器並重啓，新的接口就能夠在mock上訪問了。    而且支持json schema 驗證。 能夠解決以上全部問題。

整個流程是這樣的：

開發人員在文檔服務器編寫接口文檔，接口服務器將接口信息保存到mongo數據庫。

接口服務器向mock服務器發送請求通知它接口發生變化，mock服務重啓。 

開發環境向mock 發請求，mock 根據配置的restapi 動態生成路由攔截請求，並根據配置文mock template 作數據校驗，並返回結果。若是數據不符合接口規範，會做爲出錯信息提示出來。

 

二 同端團隊協做

因爲一些緣由，最近在改別人的代碼時候，會有一些問題。就是代碼風格，思想不一致致使的。 我以爲團隊中應該有一套規範。這個規範要從兩個方面來下手。

第一，代碼書寫規範，推薦airbnb

第二，代碼結構規範，簡單講就是分層。 分幾層，每一層作什麼，什麼樣的邏輯放在什麼樣的地方。

第三，數據庫儘可能保持一致。 同一個功能我相信你有一萬種實現方式。但理解並正確修改別人的代碼每每是困難的。數據傳遞的方式應該儘量規範一下。  如今個人代碼是根容器嵌套自子容器，子容器嵌套子組件。容器之間以及容器與組件經過prop傳遞數據（容器以前傳遞的屬性一個是config 傳遞數據對象，一個是getStoreState函數獲取父容器數據，還有一個setStoreState修改父容器數據，這樣子組件不須要引用，解耦）。容器從store  獲取數據，而後經過config順着往下流。 數據在組件中進行修改，若是須要通知其餘組件就setStoreState  若是不須要直接將數據發送出去。

還有一點是儘可能不要讓函數直接處理你的數據，更不要寫死代碼。  也就是說dont speak out your data 。 這樣能夠極大提升程序的可維護性和擴展性。

 

寫須要寫死的封裝到配置，將數據獲取封裝到純函數以外。 

三 組件封裝

目前咱們團隊就兩個前端，彼此寫的組件對方尚且不清楚到底怎麼用。 都在想有沒有什麼玄機呢？另外就是其餘團隊寫的好的組件咱們並不知道，更別說拿來主義了。

基於此，我作了一個組件平臺。這個組件平臺主要有如下幾個做用：

1. 讓人看到你有哪些組件，有哪些功能，怎麼用

2. 每個組件均可以做爲獨立發佈單元，發佈到npm上。

3. 組件和項目分離。這樣拼積木式的開發省去不少重複代碼，也就意味着代碼出bug，不須要逐一修改。

 

在這裏能夠看到全部的組件

 能夠看到組件的api文檔。

 能夠在線實驗這些組件api。

能夠直接粘貼代碼拿過去用。

四 部署問題

測試環境， uat，生產都須要發佈，每個配置都不盡相同。若是手工發佈麻煩，容易出錯，若是發佈的人不在，不熟悉發佈流程的也不肯意去抗這個鍋。 進一步考慮shell 發佈，這種的問題在於不一樣的發佈執行不一樣的腳本，對於不熟悉的人來講仍是不直觀。在這裏建議使用web管理工具好比pyledo，只要作一些配置，就能夠自動打包部署。既發揮了圖形界面的直觀，又發揮了shell的靈活。