源码管理
- 锁定默认分支
- 通过 PR 合并代码
- 每个 PR 引用相关的工作项
- Commit 历史保持连贯和一致并且保证都含有关键信息（What 和 Why）
- 约定好一致的分支命名
- 要有清晰的仓库结构文档
- 不要公开或者提交密码等隐私信息
工作追踪
- 用AzDevOps（或者是其他类似的平台，如 KB）追踪所有项目
- 经营好工作看板（包括泳道、功能标签、技术标签等）
测试
- 单元测试要覆盖到大部分组件（最好超过 90%）
- 利用 e2e 进行集成测试
持续集成 / 持续发布
- 项目中每个 PR 都做到自动测试和构建
- 在 PR 被合并前管理到副本环境的部署
- 确保主要分支已经打好镜像
安全
- 根据需求授予权限
- 密钥放在安全的地方，不要写在代码里
- 传输数据要加密并且 hash 密码
- 为了防止遭到安全攻击，确保系统的解耦性和关注点分离
监控
- 追踪关键点和函数事件并收集相关指标
- 打印应用的错误和失败日志
- 监控系统的健康状况
- 要区分客户端和服务端的监控数据
- 允许在不修改代码的情况下修改 log 配置
- 为了更好地排查生产环境的错误，在生产环境加入追踪上下文
- 确保对 PII（个人认证信息）的 GDPR 合规性
敏捷（Agile）开发
- 项目负责人（固定的或者是轮值的）进行日常进度汇报
- 在团队内部明确“敏捷开发”的定义
- 开发负责人要对积压工作的管理和优化负责
- 在团队成员和客户之间达成工作协议
设计评审
- 设计评审要写入团队内部的工作守则里
- 对主方案和备用方案里的主要组件进行评审并记录在案
- Stories 和 PRs 超链接到对应的设计文档
- 默认情况下，每个用户场景都应该包含一个在 Sprint 阶段被移除或被分配的任务
- 在项目评审提出的决定应该让受邀参加设计评审的设计顾问给予反馈
- 知悉明确的非功能性需求
代码评审
- 团队内部达成对代码评审作用的认识一致
- 在团队内部建立代码评审制度和 checklist
- 建立制度保证一个 PR 所需要的最少评审者数量（通常是 2 个）
- 配置好每个 PR 合并后的 linter 检查、单元测试和自动构建
- 拥有一个可以强制加快代码评审的流程
项目复盘
- 在每周或者是每个 sprint 结束后进行复盘
- 每周或每个 sprint 中识别出 1-3 个实验性的改进来改善进程
- 实验性改进要指定负责人并加入到项目积压问题中
- 在里程碑和项目结束时进行一次大型复盘
工程反馈
- 对阻碍项目进度的业务问题或技术问题提出反馈
- 在交付方案中包含改进建议
- 确保反馈包含详细内容并且是可复现的
开发体验
开发人员在团队中可以：
- 构建或编译代码来验证是否含有语法和编译错误
- 执行所有自动化测试（单元测试和e2e 测试等等）
- 在部署环境中开启端到端的模拟调试
- 利用调试器进行自动化测试、设置断点、逐步运行、检查变量
- 自动化安装项目依赖
- 使用本地配置开发变量
