微软的软件工程检查清单

软件工程检查清单

这是一份来自微软的软件工程检查清单，原文 是英文的，我认为对与我们很有参考性，所以将它翻译成中文，并结合我们自己的特定进行了文本的微调。

代码版本控制

• 默认主分支是被锁定的。（译者注：主分支权限控制）。
• 所有的合并都是通过提 PR/MR 完成的。
• PR/MR 都是跟任务管理系统关联的
• 提价历史记录是一致的，提交信息是信息性的（what,why）.（译者注：关于提交信息的格式，可以参考这篇文章）
• 一致的分支命名约定。（译者注：比如类型 + 任务编号）
• 清晰的存储库结构文档。（译者注：即源代码目录结构说明文档，通常应该在项目根目录README.md中提供）
• 不要将任何密码和密钥信息推送到远程仓库。

任务追踪

• 所有问题都能在任务管理系统中持续追踪（比如JIRA）
• 任务看板应该是组织良好的。

测试

• 单元测试应该覆盖所有组件（覆盖率尽可能大于90%）（译者注： 这个对于我们不太现实，但是对于一些公共组件，应该尽可能尝试写组件的单元测试）
• 端到端测试。（译者注：可以针对一些重点、高频场景进行端到端测试用例的编写）

持续集成与持续部署

• 每一个PR/MR 都应该能自动运行指定的测试用例，通过自动化测试的PR/MR才能进入评审环节。
• 在合并PR/MR之前，应该可以自动化部署到开发环境。
• 主分支上的代码应该永远处于可交付状态。

安全

• 访问权限应该仅在需要的基础上授予。（译者注：任何环境的账号，应该总是默认最小权限，只有测试确实需要使用某些模块和功能，才赋予其对应的权限）
• 密码和密钥信息应该存储到安全的地方，而不是写入代码仓库。
• 数据在传输过程中应该进行加密（如有需要，在静止状态下也可以进行加密），并对密码进行哈希处理
• 系统应该被拆分为具有关注点分离的逻辑段，这有助于限制安全漏洞。

可观察性

• 重要的业务和功能事件应该被追踪，相关的度量数据应该被收集。（译者注：即监控系统）
• 记录应用程序的故障和错误信息
• 系统的健康状态应该被监控
• 对于可观察性的数据，应该可以容易区分哪些是客户端产生的，哪些是服务端产生的
• 可以在不更改代码的情况下修改日志配置
• 传入的跟踪上下文应该被广播以便允许对生产环境问题进行调试

敏捷

• 最好进行每日站会
• 敏捷过程在团队中被明确定义
• 开发主管进行待办任务的管理和派发
• 在团队成员和客户之间建立工作协议。

设计评审

• 将设计评审包含在工作议程中
• 对解决方案中的每个主要组件进行设计评审并记录下来，包括备选方案
• 用户故事（指任务管理系统中的）和 PR/MR 应该链接到设计文档中
• 默认情况下，每个用户故事包含一个用于设计评审的任务，该任务在sprint 期间别分配或删除
• 清理非功能性需求

代码评审

• 对于代码评审的功能，团队应该有明确的共识
• 团队内部应该有一个代码检查清单
• 应该规定PR/MR的代码评审的最小参与评审人数。（通常为2个）
• 为PR/MR 合并设置代码分析器，单元测试和构建程序。
• 应该有一个可以强制执行快速审查的程序。

回顾

• 每个发版周期结束后应该进行回顾工作
• 在每个发版周期内，团队应该进行1-3个改进程序和流程（基于上一次回顾发现的问题）的实验。
• 这些实验应该具有主导者并被添加到项目的日志中。
• 团队应该考虑对里程碑和项目完成等长周期的活动的回顾

工程反馈

• 团队应该就及时就阻碍项目成功的业务和技术障碍进行反馈
• 改进建议应该被纳入到解决方案中
• 反馈是详细的并且是可复现的。

开发经验

• 开发完成要构建/编译代码，以验证它是否没有语法错误并能成功构建和编译
• 执行一遍所有的自动化测试程序（如果有的话）
• 启动端到端测试以模拟其在部署部署环境中的执行
• 使用本地开发环境配置。（如：.env 文件等）