软件工程基本原则检查表
微wx笑
2022-01-03【软件工程】
2
0关键字：
软件工程
微软公司的一份检查表，逐条列出检查点，确保项目符合软件工程的要求。
该清单有助于确保我们的项目符合我们的工程基础。
源代码管理
默认目标分支被锁定。
合并是通过 PR 完成的。
PR 引用相关的工作项。
提交历史是一致的，提交消息是信息丰富的（什么，为什么）。
一致的分支命名约定。
存储库结构的清晰文档。
秘密不是提交历史的一部分或公开的。（请参阅凭据扫描）
公共存储库遵循OSS 指南，请参阅
Required files in default branch for public repositories。
有关源代码管理的更多详细信息
工作项目跟踪
所有项目都在 AzDevOps（或类似）中进行跟踪。
董事会是有组织的（泳道、功能标签、技术标签）。
有关积压管理的更多详细信息
测试
单元测试涵盖了所有组件的大部分（如果可能，>90%）。
集成测试运行以测试解决方案 e2e。
有关自动化测试的更多详细信息
连续性/连续性
Project 运行 CI，并在每个 PR 上自动构建和测试。
在合并 PR 之前，Project 使用 CD 来管理到副本环境的部署。
主分支总是可以发货的。
安全
仅根据需要授予访问权限
机密存储在安全位置，而不是签入代码
数据在传输中被加密（如果有必要在静止时）并且密码被散列
系统是否拆分为具有关注点分离的逻辑段？这有助于限制安全漏洞。
有关安全性的更多详细信息
可观察性
跟踪重要的业务和功能事件并收集相关指标。
记录应用程序故障和错误。
系统的健康状况受到监控。
可以区分客户端和服务器端的可观察性数据。
无需更改代码即可修改日志配置（例如：详细模式）。
传入的跟踪上下文被传播以允许生产问题调试目的。
确保有关 PII（个人身份信息）的 GDPR 合规性。
有关可观察性的更多详细信息
敏捷/Scrum
流程主管（固定/轮换）运行每日站会
敏捷过程在团队中是明确定义的。
开发主管（+ PO/其他）负责积压管理和细化。
团队成员和客户之间建立了工作协议。
有关敏捷开发的更多详细信息
设计评论
进行设计审查的过程包含在工作协议中。
对解决方案的每个主要组件进行设计审查并记录在案，包括替代方案。
故事和/或 PR 链接到设计文档。
默认情况下，每个用户故事都包含一个用于设计审查的任务，该任务在 sprint 计划期间被分配或删除。
邀请项目顾问进行设计审查或要求对文档中捕获的设计决策提供反馈。
发现客户流程需要的所有评论并为它们制定计划。
捕获的明确非功能性需求（参见非功能性需求指南）
有关设计评论的更多详细信息
代码审查
团队中对代码审查的功能达成了明确的共识。
团队有代码审查清单或既定流程。
PR 合并的最少审阅者人数（通常为 2 人）由政策强制执行。
为 PR 合并设置 Linters/代码分析器、单元测试和成功构建。
有一个流程可以强制执行快速审核周转。
有关代码审查的更多详细信息
回顾展
每周/每个冲刺结束时都会进行回顾。
该团队确定了 1-3 个提议的实验，每周/冲刺尝试以改进流程。
实验有所有者并被添加到项目积压中。
团队对里程碑和项目完成进行了更长的回顾。
有关回顾的更多详细信息
工程反馈
团队提交有关阻止项目成功的业务和技术障碍的反馈
解决方案中包含了改进建议
反馈详细且可重复
开发者体验 (DevEx)
团队中的开发人员可以：
构建/编译源以验证它没有语法错误和编译。
执行所有自动化测试（单元、e2e 等）。
启动/启动端到端以模拟部署环境中的执行。
将调试器附加到已启动的解决方案或运行自动化测试、设置断点、单步执行代码和检查变量。
通过在其 IDE 中按 F5（或等效项）自动安装依赖项。
使用本地开发配置值（即 .env、appsettings.development.json）。
有关开发人员体验的更多详细信息
转自：https://microsoft.github.io/code-with-engineering-playbook/ENG-FUNDAMENTALS-CHECKLIST/
本文为转载文章，版权归原作者所有，不代表本站立场和观点。
上一篇：返回列表
下一篇：我做系统架构的一些原则
