[GitHub Global] Translate Vibe Coding 零基础教程/40 编程学习/团队研发规范.md to zh-TW

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

@@ -0,0 +1,177 @@
+# 團隊研發規範
+
+> 企業級研發規範實踐指南
+
+
+
+你好，我是程式設計師魚皮。
+
+前幾天我分享了自己創業一周年的復盤總結，其中提到了一點：隨著團隊的擴大，我們會更注重研發規範和技術沉澱。
+
+有程式設計師朋友就問了：啥是研發規範？
+
+還有朋友表示：魚皮別拿咱當外人，把你們公司的研發規範發來看看？
+
+![研發規範](https://pic.yupi.icu/1/image-20240419140208921.png)
+
+可以，必須安排！
+
+這篇文章就給大家簡單分享下我們公司的研發規範，不過在開始前必須要明確 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 信息可參考[《約定式提交》文件](https://www.conventionalcommits.org/zh-hans/v1.0.0/)，但不做強制要求。
+
+5）除非特殊情況，否則所有的代碼必須經過至少一位項目負責人 Code Review 審核通過後，才能合併；並且只有合併到主分支的代碼才允許發布上線。
+
+
+
+## 四、上線規範
+
+
+### 上線前注意事項
+
+1）上線前，除了嚴格驗證功能特性能否正常運行、並符合需求外，還要格外關注程序的：
+
+- 健壯性。比如給用戶友好的錯誤提示、輸入校驗。
+- 安全性。防止越權操作、輸入校驗。
+- 穩定性。盡量保證調用 100% 成功，如果有幾率失敗，要考慮重試或容錯策略。
+
+2）除非特殊情況，只有經過產品驗證的功能、通過代碼審核的主分支代碼才允許發布上線。
+
+3）除非特殊情況，盡量在工作日上線（建議周二 ~ 周四），保證上線後出了問題時能夠及時修復。
+
+
+
+### 上線後注意事項
+
+1）上線後，一定要再次進行完整流程的測試，尤其要重點關注權限相關的功能測試。
+
+2）上線後，一定要在群內及時同步上線信息，周知相關的成員，如果遇到問題第一時間回饋。
+
+3）首次上線後，需要即時配置監控告警。
+
+4）上線驗證通過、並經過內部群成員確認後，可以在外部用戶群發布版本更新公告。
+
+5）上線後，即時更新項目的更新記錄文件。
+
+6）注意，上線不是終點。上線後的一段時間（至少一周內），一定要持續觀察自己負責的功能是否正常運行、持續接受用戶回饋、通過數據分析來觀察新功能的效果，期間有任何問題都需要即時修復處理，並且準備好下一期的改進迭代。
+
+
+
+## 寫在最後
+
+以上就是我們公司的研發規範，希望對大家有幫助。
+
+再次強調，每個團隊都應該根據自己的情況定制研發規範，這份規範僅供參考。
+
+
+
+
+## 推薦資源
+
+1）魚皮 AI 導航網站：[AI 資源大全、最新 AI 資訊、免費 AI 教程](https://ai.codefather.cn)
+
+2）編程導航學習圈：[學習路線、編程教程、實戰項目、求職寶典、交流答疑](https://www.codefather.cn)
+
+3）程式設計師面試八股文：[實習/校招/社招高頻考點、企業真題解析](https://www.mianshiya.com)
+
+4）程式設計師寫履歷神器：[專業模板、豐富例句、直通面試](https://www.laoyujianli.com)
+
+5）1 對 1 模擬面試：[實習/校招/社招面試拿 Offer 必備](https://ai.mianshiya.com)