源码管理

  • 默认分支是否锁定
  • 是否通过PR合并分支
  • PRs引用相关工作项
  • 提交历史是一致的并且提交信息丰富（包含做了什么，为什么）
  • 一致的分支命名约定
  • 清晰的存储库结构说明文档
  • 密码等安全信息不作为提交历史的一部分或者公开
  • 公共仓库遵循OSS 规范

工作项跟踪

  • 所有个工作项在DevOps系统跟踪
  • 工作项内容是有组织的（泳道，特征标签，技术标签）

测试

  • 单元测试覆盖大部分组件（最好大于90%）
  • 集成测试按照 end-to-en测试方案进行

CI/CD

  • 项目运行 CI，并在每个 PR 上自动构建和测试
  • 在合并 PR 之前，Project 使用 CD 来管理到副本环境的部署
  • 主分支总是可以发布的

安全性

  • 仅根据需要授予访问权限
  • 密码存储在安全的位置，而不是签入代码
  • 数据在传输中被加密并且密码做hash
  • 系统是否拆分为具有关注点分离的逻辑段？这有助于限制安全漏洞

可观察性

  • 跟踪重要的业务和功能事件并收集相关指标
  • 记录应用程序故障和错误
  • 系统的健康状况受到监控
  • 可以区分客户端和服务器端的可观察性数据
  • 无需更改代码即可修改日志配置
  • 传入的跟踪上下文被传播以允许生产问题调试目的
  • 通用数据保护确保遵守个人身份信息保护条例

敏捷/SCRUM

  • 流程主管（固定/轮换）运行每日站会
  • 敏捷过程在团队中是明确定义的
  • 开发主管（+ PO/其他）负责Backlog管理和细化
  • 在团队成员和客户之间建立工作协议

设计评审

  • 进行设计审查的过程包含在工作协议中
  • 对解决方案的每个主要组件进行设计审查并记录在案，包括替代方案
  • 故事 或 需求 链接到设计文档
  • 默认情况下，每个用户故事都包含一个用于设计评审的任务，该任务在 sprint 计划期间被分配或删除
  • 邀请项目顾问进行设计评审或要求对文档中捕获的设计决策提供反馈
  • 发现客户流程所需的所有评论并为其制定计划
  • 捕捉到明确的非功能性需求

代码审查

  • 团队对代码审查的功能有明确的共识
  • 团队有代码审查清单或既定流程
  • PR 合并的最少审阅者数量（通常为 2 个）作为规范强制执行
  • 为 PR 合并设置 Linters/代码分析器、单元测试和成功构建条件
  • 有一个流程可以强制执行快速审核周转

回顾会

  • 每周/每个冲刺结束时都会进行回顾
  • 该团队确定了 1-3 个提议的实验，每周/冲刺尝试以改进流程
  • 实验项有负责人并被添加到项目Backlog
  • 团队在里程碑和项目完成后进行了更长时间的回顾总结

工程反馈

  • 团队提交有关阻止项目成功的业务和技术障碍的反馈
  • 解决方案中包含了改进建议
  • 反馈详细且可重复

开发经验

  • 构建/编译源码以验证它没有语法错误并编译通过
  • 执行所有的自动化测试（单元测试，end-to-end测试等）
  • 在部署环境启动端到端的模拟运行
  • 将调试器附加到已启动的解决方案或运行自动化测试、设置断点、单步执行代码和检查变量
  • 通过在其 IDE 中按 F5（或等效项）自动安装依赖项
  • 使用本地开发配置值（即 .env、appsettings.development.json）