需求評估
產品經理、開發工程師、測試工程師，組織需求評審會議，講解本次的開發功能。
開發需分析：
- 是否涉及到其他開發部門？
- 是否需要創建數據庫/數據表？
- 本次需要做多少頁面？
- 有多少功能點，哪些是功能難點？
根據以上，給出開發工期（X/人/天）。
跨部門溝通
溝通確定后，溝通結果以郵件的形式確認抄送相關Leader。
創建/更改 數據庫
根據公司要求規范操作數據表，確定后郵件抄送相關開發。
相關SQL語句，需要Leader、DBA 審核，方可部署。
靜態頁面開發
目前后臺項目大部分使用 BootStrap，自己拼頁面即可。
需要考慮：
- 代碼整潔性（標簽元素對齊，DIV區塊注釋）。
- 界面適配（BootStrap 柵格系統）。
- Js 相關驗證（盡量自己學js類庫，不要寫在界面中）。
- 產品驗收（確認界面元素是否滿足使用習慣）。
個人感覺界面做的漂亮，成就感也是滿滿的。
程序邏輯代碼開發
需要考慮：
- 復雜的邏輯可以自己先畫流程圖（
ProcessOn）。 - 遵循 PHP 代碼規范（
PSR）。 - 代碼注釋（重要、重要、重要）。
- 數據驗證（對前端提交的數據進行二次驗證）。
- 功能邏輯（考慮類庫封裝，代碼復用）。
- 性能問題（是否需要用到緩存）。
- 安全問題（XSS、Sql注入）。
- 日志問題（記錄相關日志）。
- 錯誤報警（可供參考）。
目前就考慮到以上這些。
功能自測
程序開發完畢后，需要自己先進行測試，走一遍全部流程。
需要考慮：
- 創建一些測試數據。
- 考慮功能的臨界值。
- 確保功能的可用性。
- 其他。
代碼評審（Code Review）
代碼評審被公認為是一個很好的提高代碼質量的手段。
好處：
- 加速個人的成長，讓自己成為一個更優秀的程序員。
- 可以分享/學習到更多的知識。
- 保證代碼清晰，容易被別人理解。
- 提前發現一些缺陷（代碼檢查者通常比代碼編寫者更挑剔）。
一些開源系統：
- Phabricator
- ReviewNinja
- Codacy
- RhodeCode
- Gerrit
如果有好的工具幫助我們進行codereview，往往會達到事半功倍的效果。
WIKI 更新
將自己開發的功能模塊，部署到WIKI上。
寫好需求方、開發者、使用者、是否用到API、相關邏輯、流程圖...
功能提測
通知測試人員，該需求可以提測啦~
根據公司要求，可以進行郵件提測，也可以JIRA管理。
以上，只是大概的講述了開發流程。
其實每一個步驟，都可以進行詳細分析，比如代碼注釋，評審規范等等。
有問題，歡迎大家留言討論。
Thanks ~
