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