要提高软件工程的质量，需要先找到一些可以衡量的维度。在改进前，先按这些维度打分，然后每隔一段时间再来打分，看看分数的变化情况。

打分可以是主观的，比如通过发送问卷调查的形式，让工程师按这些维度分别打分，再做一个汇总，得到最终的分数。

以下是一个可供参考的打分表，一共两大类，每个类别下有若干问题。

一、代码质量、持续集成/持续部署、本地开发和测试

	非常不认同	不认同	中立	认同	非常认同
代码容易理解、易于查找，有着高质量
有高效的自动化测试
有很好的自动化测试覆盖率
本地开发环境易于从 0 开始设置起来
技术债务可控，并且在持续偿还
有快速的 CI/CD 流水线
部署上线是自动化的，一周好几次
整个系统（包含所有组件）都是大家知道并且理解的
系统组件之间的交互是合理的，并且是被清晰定义过的
基础设施是独立于应用代码，通过 IaC 来部署到各个环境的
团队成员理解基础设施和其中的资源连接情况
基础设施代码有测试，并且在每次部署前都会执行这些测试
文档充分、以结构化的方式有序组织在一起，并且是最新的

二、认知负担

非常低的认知负担意味着当你在做任务时，你的大脑可以非常放松。你知道可以在哪儿找到你需要的东西，并且所有东西都会在你拿到一个新任务的同时立即清晰。

非常高的认知负担意味着当你在做任务时，你的大脑 100% 满负荷运行。你希望有更多的大脑来帮助你理清问题，以及找到解决问题的方式。

	非常低	低	一般/中等	高	非常高
内在的——如去哪里可以找到相关功能特性的代码、在哪里添加新代码等等
外部的——我怎么配置和部署一个服务呢？
综合/特殊/关键的——如服务之间该怎样交互？从产品侧过来的业务需求等

认知负担会影响团队开发新功能、为增长的用户数量而将应用扩容的能力。在软件工程中，认知负担是指在阅读软件产物（代码、如何运行服务等）时在心智努力上的花费。

每天影响开发人员的认知负荷有三种不同类型（摘自《高效能团队模式》一书）：

1. 内在认知负荷 - 与任务本身的问题领域相关（例如，如何在这个类中创建新方法？）

2. 外部认知负荷 - 与执行任务的环境相关（例如，如何部署这个组件？如何配置这项服务？）

3. 特殊/综合/关键认知负荷 - 与任务的特定学习或高性能关注相关（例如，这项服务应该如何与ABC服务互动？业务需求）

理想情况下，内在和外部认知负担都应该是低的，而特殊认知负荷，则应该在中等。

一般来说，为了有效地交付和运维现代软件系统，组织应尽量减少内在的认知负荷，消除外部的认知负荷，从而为关键认知负荷留出更多空间——而这正是“增值思维”的体现。

                                                             - 《高效能团队模式》

行动起来

不妨给自己的工程按照以上维度打个分吧，看看现状如何？并且，尝试列出改进项，并每次改进一点点，定期回顾一下吧！