一、拿到原型圖,先自我解析需求,畫出思維導圖,流程圖
-
- 在未拿到UI給定的PSD時,可以先理清我們的需求
- 依賴的外部資源
- 后端提供的接口
- UI出圖的大概布局
- 后期頻繁改動的地方
- 需要實現的效果
- 下拉刷新
- 動畫效果
- 吸頂效果
- 懶加載、預加載、防抖、節流
- 依賴的外部資源
- 在未拿到UI給定的PSD時,可以先理清我們的需求
二、產品召集項目相關人員,開需求討論會,產品講解原型
-
- 理解產品的需求,提出質疑:這是什么功能,怎么做,為啥這么做
- 評估實現難度和實現成本,是否有潛在技術問題/風險
- 對比自己整理的需求圖,如果有和自己想的不符合的,提出疑問
- 理解PM提出此次需求的目的,明白哪些內容是重點,哪些次要,可以適當取舍
- 如果產品要求提供時間,簡單項目可以預估,復雜項目不可馬上給出時間,需要仔細評估,評估時間包含開發、自測、測試人員測試、修復bug、上線准備
三、會后進一步整理需求
-
- 細化細節,整理有疑問的地方,與產品、設計等其他人進行確認
- 評估項目完成時間--影響因素
- 需要的人力、 中間插入的需求、 開發、 自測、 測試人員測試、 修復bug、 上線准備、 其他風險(如技術選型錯誤等)
- 初步制定排期表
四、需求二次確認(開發中遇到不確定的,依舊需要找相關人員進行需求確認,杜絕做無用功)
-
- IM工具溝通確認
- 郵件確認
- 小型需求/項目相關討論會
- 確定最終排期表
- IM工具溝通確認
五、開發
-
- 技術選型
- 搭建開發環境
- 工具鏈
- 搭建項目架構
- 業務模塊划分
- 優先級排序
- 新項目介入,需要當前項目和介入項目的相關負責人Pk優先級,隨后調整項目排期
- 開發過程中發現工作量與預期有嚴重出入,需要盡早向其他項目人員反饋,方便其修改時間安排
- 定制開發規范
- 開發規范
- commit提交格式
- [改動文件類型]:[改動說明]
- 單分支開發或者多分支開發
- 小項目、並行開發少,則只在master主分支開發
- 中大項目,需求復雜,並行功能多,則需要分為master、developer、開發者分支;需要開發者自創一個分支開發,合並到developer,確認無問題后,發布到master,最后上線
- commit提交格式
- 代碼規范
- jsconfig.json
- .postcssrc.js
- .babelrc
- .prettierrc(vscode插件prettier-code fomatter)— 注意與eslint要保持一致
- .editorconfig
- .eslintrc.js(強制開啟驗證模式)
- JavaScript開發中常用的代碼規范配置文件
- 源碼管理
- 版本管理
- 安全管理
- 開發規范
六、自測
-
- 手動測試
- 單元測試
- mocha
- 集成測試
七、提測---測試人員測試
-
- 開發人員修復bug
- 期間不可接手耗時大的需求
- 有不確定優先級高低的需求,需要各個需求方互相pk優先級,再確定做與不做,不能因此拖延項目完成點
- 測試修復bug時間可能比開發時間還長,因此開發者預估開發時間不能樂觀
八、上線
-
- 上線准備
- 域名申請
- 備案申請
- 服務器申請
- 部署
- 測試線上環境
- 有bug回到修復bug環節
- 日志監控
- 調用棧
- sourcemap
- 本地日志
- 用戶環境、IP
- 低成本接入
- 統計功能
- 報警功能
- 上線准備
九、維護
-
- 技術創新(對現有的技術領域以及具體項目實現方法進行優化)
- 提高效率
- jenkins構建部署
- 減少成本
- 提升穩定性
- 安全性
- 提高效率
- 技術創新(對現有的技術領域以及具體項目實現方法進行優化)
