如何衡量一个软件工程的质量?

哈德韦

共 2488字,需浏览 5分钟

 ·

2023-10-14 12:54

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


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


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


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



非常不认同

不认同

中立

认同

非常认同

代码容易理解、易于查找,有着高质量






有高效的自动化测试






有很好的自动化测试覆盖率






本地开发环境易于从 0 开始设置起来






技术债务可控,并且在持续偿还






有快速的 CI/CD 流水线






部署上线是自动化的,一周好几次






整个系统(包含所有组件)都是大家知道并且理解的






系统组件之间的交互是合理的,并且是被清晰定义过的






基础设施是独立于应用代码,通过 IaC 来部署到各个环境的






团队成员理解基础设施和其中的资源连接情况






基础设施代码有测试,并且在每次部署前都会执行这些测试






文档充分、以结构化的方式有序组织在一起,并且是最新的







二、认知负担

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


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



非常低

一般/中等

非常高

内在的——如去哪里可以找到相关功能特性的代码、在哪里添加新代码等等






外部的——我怎么配置和部署一个服务呢?






综合/特殊/关键的——如服务之间该怎样交互?从产品侧过来的业务需求等






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



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

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

  2. 外部认知负荷 - 与执行任务的环境相关(例如,如何部署这个组件?如何配置这项服务?)

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

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

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

                                                             - 《高效能团队模式》


行动起来


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

浏览 38
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报