從零開始搞基建（2）——團隊協做規範

      前端會與公司的全部部門有協做，若在某一環出現問題，就會發生沒必要要的時間開銷，下降開發效率。因此有必要制訂一套完善的協做流程。

      有個核心要素，那就是積極主動性。

1、與業務方的協做

1）BUG上報

      業務方包括運營、客服、財務等部門，在使用軟件時不免會遇到這樣那樣的問題。

      若要上報這些BUG，則須要提供頁面地址、問題描述、截圖和機型，若是能夠提供錄像的話，那最好了。

      還能夠提供一些其餘線索，諸如誰誰誰以前處理過該類問題，線索越多，定位問題的速度越快。

      注意，頁面地址是必填項，有了地址前端這邊才能準確的定位到問題和相關責任人。

2）業務需求

      在提出業務需求後，須要提供一些基礎保障，幫助研發或測試，例如開通海外PayPal支付，須要提供測試用的海外帳號。

      實時更改需求池任務的狀態，沒必要特意去通知業務方需求已上線。

3）維護

　　當有重要活動或業務上線時，需攜帶公司筆記本回去，及時修復線上問題。

　　通常狀況下，若出現線上問題，先定位問題出現的位置，而後重啓相關服務便可。

2、與設計的協做

1）定稿

      設計至少應在開發開始時敲定終稿，後面修改最多隻作微調。

2）交互

      設計想要的交互動畫，能夠製做成一段 mp4 視頻給到前端。

      而且前端會提出可能存在的問題（技術實現問題、性能問題等），協商解決方案（如優雅退化）並達成共識。

3）覈對

      前端拿到設計稿後，與產品文檔比對，當與產品原型不符時，要主動找產品和設計覈對。

      當前端收到新的設計稿與原先提供的有差別時，需主動與產品溝通。

4）驗收

      在完成頁面的開發後，讓設計確認驗收，可在工做羣中@相關人員，讓他們確認回覆。

3、與產品的協做

1）產品文檔

      產品應在文檔中補全設計搞（上傳設計稿圖像或加個藍湖地址），如有修改，則最好標明修改的位置，好讓前端和測試作驗收。

      產品在設計產品文檔時，得保證相關流程的完整性，例如新增一個支付渠道，那麼就得把後臺管理界面也寫到文檔中。防止在開發過程當中臨時加需求，打亂總體節奏。

      前端必須仔細閱讀產品文檔，力求理解業務需求，杜絕因爲需求模糊而發生的反覆修改。

2）肯定開發人員

      在正式開發前，產品須要確認相關功能由哪一端完成，這部分主要涉及的是前端和客戶端，以避免在開發時臨時修改技術方案。

3）覈對

      當文案發現有差別時，需主動與利益相關方覈對，例如測試、產品、設計等。

4）權限

      新功能提測與上線後，前端主動給相關人員開權限，不要再次提醒。

5）預估時間

      根據項目時間要求及工做量，預估時間，精確到小時，在完成預估後主動提供給產品。

      當須要預估提測時間時，最好將平時救火的時間也考慮進去，時間不要估的太緊。

4、與服務端的協做

1）接口文檔

      在開發伊始，就得先定好接口說明，既能夠是規範的文檔，也能夠是JSON文件，只要能說明字段便可。

      不要出現誰等誰的狀況，這樣既費時又耗感情。

2）技術細節

      在須要互相協做時，須要先明確各個技術點，儘可能作到在正式開發前就對好技術細節，避免返工。

　　在與其餘組溝通細節以前，須要本身瞭解清楚當前的產品需求，以及當前的系統狀況。

　　他們推薦的方案能夠做爲資料參考，但切記不要被他們影響本身的思路，咱們要按本身的實際狀況給出最適合的方案。

　　務必要將技術細節確認好，即便是一個數據庫表的字段也要覈對好，不要有歧義。

3）建表

　　在建表以前，須要先和服務端溝通清楚，從新建表合適，仍是在原表上新增字段合適。

　　在初步溝通完成後，最好再看看當前數據庫中是否有類似功能的表，由於服務端的人頗有可能剛接手，並不瞭解當前的數據庫。

5、與測試的協做

1）測試用例

      在需求確認後的兩天，測試整理出測試用例，開發在完成頁面後，主動執行部分測試用例，減小沒必要要的糾纏時間。

      若某個用例的執行成本較高，則略過，例如須要造不少複雜的數據。

      一般測試用例會包含許多功能點，但至少要將核心流程的功能點跑一下。

2）結對編程

      將代碼的大體邏輯講解給測試聽一下，作次簡單的結對編程，這麼作可發現一些開發忽略的潛在問題。