Engineering Fundamentals Checklist（微软软件工程基础检查表）
微软的软件工程基础检查表
可以用于查看自己团队还有哪些不足。
翻译自 Engineering Fundamentals Checklist
代码控制
- 默认目标分支已锁定。
- 通过PR合并了分支。
- PR和工作项建议了引用。
- 提交历史是一致的，并且提交信息是翔实的（提交了什么，为什么提交）。
- 分支名称与约定一致。
- 清晰的文档和代码库结构。
- 保密信息没有包含在提交中，没有被公开。
- 开源库遵循OSS指引。
工作项追踪
- 所有工作项在AzDevOps中可追踪（或者Jira, Teambition）。
- 工作项管理系统仪表板是组织结构清晰的。
测试
- 单元测试覆盖大多数组件（>90%如果可能）。
- 集成测试达到端到端（End to end testing）。
CI/CD
- Project 运行 CI 并在每个 PR 上自动构建和测试。
- 在合并 PR 之前，项目使用 CD 来管理到副本环境的部署。
- Main分支保持随时可以发版的。
安全
- 权限访问总是给到最低要求权限。
- 保密信息总是保存在安全的位置不能出现在代码中。
- 数据在传输过程中加密（如有必要，在静止时）并对密码进行哈希处理。
- 系统是否为逻辑和关注点分离的，这有助于限制安全漏洞。
可观察性
- 重要的业务和功能事件被跟踪，并收集相关指标。
- 程序错误和故障已被记录。
- 系统健康状况已被监控。
- 客户端和服务器端的可观察性数据可以被区分开来。
- 无需更改代码即可修改日志记录配置。
- 传入的跟踪上下文被分发，以允许生产问题调试的目的。
- 亲自识别GDPR合规性。
敏捷/Scrum
- 每日站会按时举行。
- 敏捷流程已和团队成员清晰定义。
- 开发老大（PO/其它关键老大）负责项目积压的管理和精细化工作。
- 在团队成员和客户之间建立了一个确切的工作协议。
设计审查
- 设计审查流程包含在工作协议中。
- 对解决方案的每个重要组件进行了设计审查并记录且有替代方案。
- 用户故事或者PR关联了设计文档。
- 每个用户故事包含一个设计审查的任务，可以在冲刺的时候修改或者删除。
- 项目顾问被邀请参加设计审查，或者对设计审查文件给出反馈意见。
- 发现客户流程所需的所有审查，并对其进行规划。
- 捕获清晰的非功能性需求。
代码审查
- 团队就代码审查达成了清晰的协议。
- 团队中有代码审查的确认表或流程。
- 强制执行的政策规定了PR合并的最低审查人数（通常为2人）。
- PR中设置了代码分析，单元测试，成功构建。
- 有一个强制执行的快速审查流程。
回顾
- 每个冲刺结束有进行回顾。
- 团队在每个回顾中提出1到3个改善实验以优化流程。
- 实验有负责人，并且添加到项目积压中。
- 为里程碑和项目完成进行更长的回顾。
软件工程反馈
- 团队提交有关阻止项目成功的业务和技术障碍。
- 建议中包含改进方案。
- 反馈详细且可重复。
开发者经验
- 构建编译源代码以验证它没有语法错误。
- 执行所有自动测试。
- 启动端到端模拟以确定部署环境。
- 将调试器附加到开始的解决方案或运行的自动测试中，设置断点，逐步通过代码，并检查变量。
- 在IDE中自动安装依赖包。
- 使用本地开发配置参数。
