偷偷分享下我们公司的研发规范

偷偷分享下我们公司的研发规范

项目整体研发流程

• 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 信息中提供代码改动说明，还可以通过关联需求文档、测试用例、方案文档、效果截图等方式进行补充说明。

上线规范

上线前注意事项

• 1）上线前，除了严格验证功能特性能否正常运行、并符合需求外，还要格外关注程序的：
  • 健壮性。比如给用户友好的错误提示、输入校验。
  • 安全性。防止越权操作、输入校验。
  • 稳定性。尽量保证调用 100% 成功，如果有几率失败，要考虑重试或容错策略。
• 2）除非特殊情况，只有经过产品验证的功能、通过代码审核的主分支代码才允许发布上线。
• 3）除非特殊情况，尽量在工作日上线（建议周二 ~ 周四），保证上线后出了问题时能够及时修复。

上线后注意事项

• 1）上线后，一定要再次进行完整流程的测试，尤其要重点关注权限相关的功能测试。
• 2）上线后，一定要在群内及时同步上线信息，周知相关的成员，如果遇到问题第一时间反馈。
• 3）首次上线后，需要即时配置监控告警。
• 4）上线验证通过、并经过内部群成员确认后，可以在外部用户群发布版本更新公告。
• 5）上线后，即时更新项目的更新记录文档。
• 6）注意，上线不是终点。上线后的一段时间（至少一周内），一定要持续观察自己负责的功能是否正常运行、持续接受用户反馈、通过数据分析来观察新功能的效果，期间有任何问题都需要即时修复处理，并且准备好下一期的改进迭代。