要提高软件工程的质量，需要先找到一些可以衡量的维度。在改进前，先按这些维度打分，然后每隔一段时间再来打分，看看分数的变化情况。
打分可以是主观的，比如通过发送问卷调查的形式，让工程师按这些维度分别打分，再做一个汇总，得到最终的分数。
以下是一个可供参考的打分表，一共两大类，每个类别下有若干问题。
一、代码质量、持续集成/持续部署、本地开发和测试
| 非常不认同 | 不认同 | 中立 | 认同 | 非常认同 | |
|---|---|---|---|---|---|
| 代码容易理解、易于查找，有着高质量 | |||||
| 有高效的自动化测试 | |||||
| 有很好的自动化测试覆盖率 | |||||
| 本地开发环境易于从 0 开始设置起来 | |||||
| 技术债务可控，并且在持续偿还 | |||||
| 有快速的 CI/CD 流水线 | |||||
| 部署上线是自动化的，一周好几次 | |||||
| 整个系统（包含所有组件）都是大家知道并且理解的 | |||||
| 系统组件之间的交互是合理的，并且是被清晰定义过的 | |||||
| 基础设施是独立于应用代码，通过 IaC 来部署到各个环境的 | |||||
| 团队成员理解基础设施和其中的资源连接情况 | |||||
| 基础设施代码有测试，并且在每次部署前都会执行这些测试 | |||||
| 文档充分、以结构化的方式有序组织在一起，并且是最新的 |
二、认知负担
非常低的认知负担意味着当你在做任务时，你的大脑可以非常放松。你知道可以在哪儿找到你需要的东西，并且所有东西都会在你拿到一个新任务的同时立即清晰。
非常高的认知负担意味着当你在做任务时，你的大脑 100% 满负荷运行。你希望有更多的大脑来帮助你理清问题，以及找到解决问题的方式。
| 非常低 | 低 | 一般/中等 | 高 | 非常高 | |
|---|---|---|---|---|---|
| 内在的——如去哪里可以找到相关功能特性的代码、在哪里添加新代码等等 | |||||
| 外部的——我怎么配置和部署一个服务呢？ | |||||
| 综合/特殊/关键的——如服务之间该怎样交互？从产品侧过来的业务需求等 |
认知负担会影响团队开发新功能、为增长的用户数量而将应用扩容的能力。在软件工程中，认知负担是指在阅读软件产物（代码、如何运行服务等）时在心智努力上的花费。
每天影响开发人员的认知负荷有三种不同类型（摘自《高效能团队模式》一书）：
- 内在认知负荷 - 与任务本身的问题领域相关（例如，如何在这个类中创建新方法？）
- 外部认知负荷 - 与执行任务的环境相关（例如，如何部署这个组件？如何配置这项服务？）
- 特殊/综合/关键认知负荷 - 与任务的特定学习或高性能关注相关（例如，这项服务应该如何与ABC服务互动？业务需求）
理想情况下，内在和外部认知负担都应该是低的，而特殊认知负荷，则应该在中等。
一般来说，为了有效地交付和运维现代软件系统，组织应尽量减少内在的认知负荷，消除外部的认知负荷，从而为关键认知负荷留出更多空间——而这正是“增值思维”的体现。 - 《高效能团队模式》
行动起来
不妨给自己的工程按照以上维度打个分吧，看看现状如何？并且，尝试列出改进项，并每次改进一点点，定期回顾一下吧！