究竟什麼樣的開發流程是規範的？

概述

有讀者反饋，讀了文章 一線技術管理者究竟在管什麼事？ 收穫滿滿，但還有點不過癮，還想了解更細的東西...

這篇文章分享開發流程規範，目的是提升產品質量，優化開發流程，供你們參考。

規範是死的，人是活的，但願本身定的規範，不要被打臉。

接下來從以上六個階段進行逐一拆解。

1 需求評審

做爲技術人員確定都參加過需求評審會，不知道有沒有遇到這樣的狀況？

• 產品經理按照 PRD 文檔讀一遍，參會人員無動於衷。
• 產品經理剛講了一個需求點，參會人員就產生了激烈的討論，都在證實本身是對的。
• 參會人員對需求的目標不明確，對需求點進行發散思惟討論，最終偏離方向。

遇到以上問題，確定是在參加需求評審以前未作充分準備，那麼問題來了，須要提早準備什麼？

評審前

不要聽產品同窗說，該需求是大老闆跟進的、很是重要、很是緊急之類的，就問產品三個問題：

1. 解決了什麼問題？
2. 提高了什麼指標？
3. 有什麼商業價值？

這三個問題搞清楚了，再進行評審。

產品經理髮出 原型 和 PRD 初稿後，開發人員要有 1-2 天時間（具體時間根據項目大小而定），熟悉文檔，有任何疑問能夠反饋給開發經理，由開發經理統一收集再反饋給產品經理，產品經理逐一進行答疑。

熟悉完文檔後，開發人員和開發經理須要一塊兒肯定：

• 技術選型（前端/後端框架、日誌中間件、消息中間件、數據庫...）
• 技術架構（組件與組件之間如何協同工做，如何部署）
• 技術難點預知（明確存在的技術難點，並肯定解決方案）
• 性能瓶頸預知（明確可能存在性能瓶頸的地方，並肯定應對措施）
• 上下游系統交互（明確在流程中的哪一個位置，約定接口文檔提供時間、接口聯調時間）
• 功能模塊劃分（任務拆分和分配）

技術方案肯定後，須要輸出技術設計文檔，包括：整體設計、概要設計、詳細設計、接口設計 等。

評審中

開發人員必須參加，有需求不明確的地方當場提出，同時開發人員也須要思考產品需求是否合理，可適當提出本身的產品意見。

通常評審至少有兩次（初稿和終稿）。

評審後

評審後，若有需更新技術文檔的請及時進行更新。

開發經理首先須要考慮團隊現有的資源及項目的優先級，而後根據技術設計文檔進行評估排期。

排期模板以下：

2 技術評審

評審前

開發人員必定要重視技術設計！

開發人員必定要重視技術設計！

開發人員必定要重視技術設計！

重要事情說三遍！

技術評審主要評審什麼？

• 系統關係圖、模塊關係圖、流程圖的設計，畫圖工具根據本身愛好便可。
• 接口設計，須要考慮接口的 兼容性、擴展性、參數命名遵照 參數命名規範 等。
• 數據庫設計，須要遵照 數據庫設計規範，並記錄 數據表變動文檔。
• 詳細設計，須要考慮公共類、公共方法、方法定義 遵照 項目框架目錄規範。

評審中

開發人員和開發經理必須參加，涉及到整體設計和概要設計時，須要邀請 架構師 參與，涉及到數據庫調整時，須要邀請 DBA 參與。

通常評審至少有兩次（初稿和終稿）。

評審後

評審後，若有需更新排期文檔的請及時進行更新。

排期肯定後，經過郵件方式進行回覆排期，使用標準化的 回覆排期郵件模板。

循序漸進，按計劃行事。

3 需求開發

編碼

開發人員編碼過程當中，須要遵照團隊的 編碼規範，同時嚴格按照設計文檔中的技術方案執行，除了保證代碼邏輯的正確性外，還須要考慮代碼封裝性、可維護性、可擴展性，當編碼階段發現技術方案須要調整時，須要及時通知開發經理，通過贊成後才能實施，涉及到引入新框架和新技術，也須要提早通知開發經理。

代碼審查

開發人員須要控制代碼提交的頻次和粒度，每次代碼提交以後 24 小時內，須要主動聯繫代碼審查人完成檢查，開發經理負責檢查是否執行到位。

代碼審查主要審查什麼？

• 規範性檢查（是否符合代碼規範、提交備註規範等）
• 健壯性檢查（是否陷入死循環、資源未釋放等）
• 安全性檢查（是否存在SQL注入、XSS、SSRF、CSRF、越權、文件上傳等）
• 性能檢查（是否存在未加緩存頻繁鏈接DB，是否須要鏈接池）

聯調

開發人員積極主動地推進聯調工做，若是遇到阻礙及時通知技術經理進行協調。

自測

聯調完畢後，開發人員須要同時完成自測，並將標準化的 自測報告 發給測試團隊。

對於有性能要求的項目，須要開發人員進行性能測試，並出具標準化的 性能測試報告。

提測

自測完畢後，經過郵件方式進行提測申請，使用標準化的 申請提測郵件模板。

開發人員根據公司運維提供的發佈方式，進行部署到測試環境。

4 跟進測試

測試用例評審

開發人員必須參加，避免出現測試與開發對需求理解不一致的狀況。

Bug 修復

開發人員及時關注 Bug 列表，快速修復迭代發佈，若是測試進度存在延期風險，須要及時通知開發經理。

5 跟進上線

開發人員首先確認 Bug 所有關閉，同時產品人員在測試環境驗收經過，而後須要主動推進相關團隊理清上線依賴和上線順序，同時肯定回滾預案，最後根據公司運維提供的發佈方式，進行部署到線上環境。

線上環境部署完成後，經過郵件方式進行通知產品人員和測試人員，使用標準化的 上線完畢郵件模板，同時積極推進測試人員和產品人員完成線上驗證，線上出現問題後第一時間通知開發經理。

6 線上問題覆盤

需求在測試環境和正式環境，均未測試出 Bug，上線一段時候後出現 Bug，這種問題用什麼制度約束？

出現問題後開發人員及時修復，修復完了就完事了。僅僅作到這些還遠遠不夠。

建議使用以下模板進行復盤。

小結

你們能夠數一數上面使用到了多少規範，這時有朋友會說了，這規範也太多了吧，這和工廠工人有什麼區別，咱們程序員是有創造性的，咱們喜歡前沿性、挑戰性的工做，咱們放蕩不羈愛自由...

針對這個問題，首先我不否定開發人員是有創造性的，但並非全部的程序員都有創造性，在現實工做場景中大部分程序員不是作創造性工做的，也不必作創造性工做，因此必須按照規範流程執行。

團隊管理和團隊之間合做，必需要有規範，並嚴格執行。

就到這吧，以上供參考。

推薦閱讀

• Git 分支設計規範
• API 接口設計規範
• 一線技術管理者究竟在管什麼事？
• 一我的被提拔，不只僅是能力，而是信任