需求評估
產品經理、開發工程師、測試工程師，組織需求評審會議，講解本次的開發功能。
開發需分析：
-
是否涉及到其他開發部門？
-
是否需要創建數據庫/數據表？
-
本次需要做多少頁面？
-
有多少功能點，哪些是功能難點？
根據以上，給出開發工期（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管理。
以上，只是大概的講述了開發流程。
其實每一個步驟，都可以進行詳細分析，比如代碼註釋，評審規範等等。
有問題，歡迎大家留言討論。