微软的软件工程基础检查表
对于了解大公司的工作流程有一定的帮助。
(翻译自)[https://microsoft.github.io/code-with-engineering-playbook/ENG-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中自动安装依赖包。
使用本地开发配置参数。