大家好，我是程式設計師魚皮。前幾天我分享了自己 ，其中提到了一點：隨著團隊的擴大，我們會更註重研發規範和技術沈澱。
有程式設計師朋友就問了：啥是研發規範？
還有朋友表示：魚皮別拿咱當外人，把你們公司的研發規範發來看看？
可以，必須安排！
這篇文章就給大家簡單分享下我們公司的研發規範，不過在開始前必須要明確 2 點：
每個團隊都應該根據情況客製自己的研發規範，別人的規範僅供參考，未必最適合你們團隊。
篇幅有限，本文僅分享一些我認為很重要的規範，並且移除了我們自己的敏感資訊。
一、計畫整體研發流程
1）團隊共同確認目標和規劃
開會討論，產出目標和規劃文件
2）產品調研和需求分析
產出調研報告和需求分析文件
3）需求評審
開需求評審會，明確要做的需求和工作，評估工作量並明確工作時間節點。
4）方案設計
產出方案設計文件，比如資料庫表設計、頁面設計、介面設計等。
5）研發
包括各自開發、單元測試、前後端聯調等
6）測試和驗收
包括研發自測、產品驗收、組內驗收等
7）程式碼送出
送出可上線的程式碼，需要由負責人審查，透過後可合並
8）部署上線
將程式碼釋出到伺服器上，組內進行上線通知並更新上線文件，上線後需要自行驗證
9）產品叠代
持續收集使用者對新功能的反饋、並進行數據分析，從而驗證改動效果，便於下一輪的更新叠代。
二、開發規範
開發前註意事項
1）確保自己充分理解了業務和需求，需要先進行整體的方案設計；尤其是對於重要需求和核心業務，必須先跟組內同學核對方案並透過後，才能下手開發，避免重復工作。
2）先熟悉計畫再開發，建議閱讀計畫文件、計畫程式碼、介面文件、前端元件文件等。
3）慎重引入新的依賴或類別庫、或者升級版本，重大依賴變更需要和組內其他成員確認。
4）熟悉團隊已實作的功能和程式碼，盡量復用，避免重復開發。
5）熟悉團隊內部的研發規範，並在 IDE 中進行相應的配置，比如前端配置 ESLint、Prettier 等程式碼規範外掛程式。
開發中註意事項
1）開發新功能時，確保從計畫倉庫拉取 最新主分支 的程式碼。
2）每個功能都要新建自己的分支進行開發， 千萬不要直接修改主分支的程式碼 ！註意分支名稱要使用英文、足夠語意化，不要和其他人的混淆。
3）開發時，盡量復用現有的功能、模組、類、方法、物件程式碼。有現成的程式碼，就不要再重復編寫。如無法復用，可以適當透過註釋說明。
4）開發時，遵循團隊內部的研發規範，盡量參考現有計畫程式碼的寫法，尤其是不要使用和原計畫不一致的格式、命名、寫法，避免特立獨行。
5）開發過程中，有任何不明確的地方，不要憑空猜測，及時去聯系計畫的其他成員或負責人確認。
6）開發過程中，每隔一段時間（比如 1 - 3 天）可以使用
git pull
同步一下最新的主分支程式碼，防止合並程式碼沖突。
7）開發過程中，註意整體時間進度的把控，先完成再完美，有風險時及時反饋。
8）開發時，需要格外註意對異常情況的捕獲和處理。
9）每個分支盡量保證純凈，盡量減少每次開發和送出時改動的程式碼量。建議每次開分支只改一個功能、Bug 或模組，不要把多個不相關的功能寫在一起，並且非必要不修改。
10）完成部份功能開發後，一定要自測！自測時，可以 Mock 假數據。 註意一定不要線上上測試、一定不要影響線上數據！
三、程式碼送出規範
1）只有透過測試和產品驗收的程式碼，才能夠發起合並到主分支的 PR 請求。在這之前可以送出到自己的分支。
2）發起合並到主分支的 PR 前， 一定要完整閱讀 3 遍自己的程式碼 ，避免不規範的寫法和無意義的改動。
3）每次合並盡量只專註於一個功能或改動，避免多個功能耦合在一起合並，提高審查效率並降低改動風險。
4）每次送出時，需要在 commit 資訊中提供程式碼改動說明，還可以透過關聯需求文件、測試用例、方案文件、效果截圖等方式進行補充說明。
commit 資訊可參考【約定式送出】文件，但不做強制要求。
5）除非特殊情況，否則所有的程式碼必須經過至少一位計畫負責人 Code Review 稽核透過後，才能合並；並且只有合並到主分支的程式碼才允許釋出上線。
上線規範
上線前註意事項
1）上線前，除了嚴格驗證功能特效能否正常執行、並符合需求外，還要格外關註程式的：
健壯性。比如給使用者友好的錯誤提示、輸入校驗。
安全性。防止越權操作、輸入校驗。
穩定性。盡量保證呼叫 100% 成功，如果有機率失敗，要考慮重試或容錯策略。
2）除非特殊情況，只有經過產品驗證的功能、透過程式碼稽核的主分支程式碼才允許釋出上線。
3）除非特殊情況，盡量在工作日上線（建議周二 ~ 周四），保證上線後出了問題時能夠及時修復。
上線後註意事項
1）上線後，一定要再次進行完整流程的測試，尤其要重點關註許可權相關的功能測試。
2）上線後，一定要在群內及時同步上線資訊，周知相關的成員，如果遇到問題第一時間反饋。
3）首次上線後，需要即時配置監控告警。
4）上線驗證透過、並經過內部群成員確認後，可以在外部使用者群釋出版本更新公告。
5）上線後，即時更新計畫的更新記錄文件。
6）註意，上線不是終點。上線後的一段時間（至少一周內），一定要持續觀察自己負責的功能是否正常執行、持續接受使用者反饋、透過數據分析來觀察新功能的效果，期間有任何問題都需要即時修復處理，並且準備好下一期的改進叠代。
👇🏻 點選下方閱讀原文，獲取魚皮往期編程幹貨。
往期推薦
