前端開發流程

一. 需求

1.1 評審

• 召集需求涉及到的UI、開發、產品、測試人員整理業務流程，同步信息，明確分工
• 明確需求目的，考慮當前需求設計是否可知足目的
• 整理流程中若是涉及的其餘人員，則召集商討
• 如需求設計上影響現有業務功能，應要求產品從新設計實現方案，而後從新評審

1.2 注意事項

• 業務流程同步：評審後從新梳理流程，存在疑問處及時找產品溝通
• 周邊需求依賴：評審功能與依賴功能並行開發，因爲前置需求未完成致使當前需求時間成本被壓縮
• 埋點需求：提早與產品明確是否須要埋點
• 造數據：提早了解測試數據製造的困難程度，預估測試時間--->有些場景下的測試數據很是難造
• 併發量：後端機器是否可以承擔新需求下的併發量，若是沒法承擔的話必須給出後續方案
• 自測：因爲開發人員不予提供線上帳號，所以自測也須要一名測試人員作線上迴歸測試
• 兼容範圍：pc端需明確要兼容哪些瀏覽器，移動端需明確android與ios兼容版本以及哪些移動端瀏覽器

二. 開發

2.1 評審

2.1.1 原型圖評審

• 向產品明確原型圖在應用中所處位置以及入口的顯示條件，確認原型圖的正確性

2.1.2 設計稿評審

• 觀察線上應用設計風格與當前設計稿風格是否一致(色調，字號，行高，對齊方式)是否一致
• 觀察設計稿中哪些部分須要切圖
• 判斷設計稿中組件是否開發過，避免重複造輪子

2.1.3 技術實現評審

• 如存在不易實現的功能，第一時間與產品溝通其餘降級的實現方案

2.1.4 排期

• 找到相關開發(前端，後端，app)商討需求實現技術細節，明確產出接口格式時間與接口聯調時間

2.2 代碼管理

爲防止合併代碼時過多的代碼衝突問題，建議使用分支時遵循如下標準

• 每次push前先拉取線上分支代碼
• 開發新功能或者修復bug時必定要基於線上代碼分支建立新分支，每一個分支只對應一個jira號或一個待修復的bug問題
• 分支名以f_(提交人)_(jira號)方式命名，對jira進行bug修復時使用f_(提交人)_fix_(bug內容)_(jira號)
• commit格式規則：每行message描述一個功能點，message格式爲$(操做)：$(描述)，操做通常爲add,del,upd分別表明新增、刪除、更新三種操做

2.3 開發與調試

通常開發時不會從造輪子開始，項目中通常會有組件庫供開發人員使用，但也會有一些老舊的項目中組件庫版本較低，沒法知足需求，
所以在開發前必定要對項目現有組件進行評估，確認是否須要從新開發組件，確保進度如期進行。

2.3.1 pc端

推薦優雅降級方式開發，先chrome，firefox，而後再針對兼容性較差的如ie等進行兼容處理

2.3.2 移動端

移動端頁面兼容性相較於pc端較好，但需真機調試，爲方便調試移動頁面，這裏推薦使用spy-debugger來讓pc端作代理，具體使用
請查閱github文檔。

2.4 自測

自測環節與環境數據關聯很大，須要先後端共同完成，若是自測所需數據涉及範圍較廣，則須要找齊相關人員協助