Files
ai-guide/translations/zh-TW/Vibe Coding 零基础教程/40 编程学习/团队研发规范.md
T

7.2 KiB
Raw Blame History

團隊研發規範

企業級研發規範實踐指南

你好,我是程式設計師魚皮。

前幾天我分享了自己創業一周年的復盤總結,其中提到了一點:隨著團隊的擴大,我們會更注重研發規範和技術沉澱。

有程式設計師朋友就問了:啥是研發規範?

還有朋友表示:魚皮別拿咱當外人,把你們公司的研發規範發來看看?

研發規範

可以,必須安排!

這篇文章就給大家簡單分享下我們公司的研發規範,不過在開始前必須要明確 2 點:

  1. 每個團隊都應該根據情況定制自己的研發規範,別人的規範僅供參考,未必最適合你們團隊。
  2. 篇幅有限,本文僅分享一些我認為很重要的規範,並且移除了我們自己的敏感信息。

本文對應影片版:https://bilibili.com/video/BV1fi421C78M

一、項目整體研發流程

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)注意,上線不是終點。上線後的一段時間(至少一周內),一定要持續觀察自己負責的功能是否正常運行、持續接受用戶回饋、通過數據分析來觀察新功能的效果,期間有任何問題都需要即時修復處理,並且準備好下一期的改進迭代。

寫在最後

以上就是我們公司的研發規範,希望對大家有幫助。

再次強調,每個團隊都應該根據自己的情況定制研發規範,這份規範僅供參考。

推薦資源

1)魚皮 AI 導航網站:AI 資源大全、最新 AI 資訊、免費 AI 教程

2)編程導航學習圈:學習路線、編程教程、實戰項目、求職寶典、交流答疑

3)程式設計師面試八股文:實習/校招/社招高頻考點、企業真題解析

4)程式設計師寫履歷神器:專業模板、豐富例句、直通面試

51 對 1 模擬面試:實習/校招/社招面試拿 Offer 必備