代码质量第 5 层 - 只是实现了功能
产品实现的功能是产品价值的体现形式。功能实现是基础。功能没有实现,其他方面做得再好也没有意义。那么,如何保证实现的功能覆盖了需求呢?
产品实现的功能是产品价值的体现形式。功能实现是基础。功能没有实现,其他方面做得再好也没有意义。
本文主要内容如下:
- 如何做到:实现的功能覆盖了需求。
- 仅仅实现了功能有什么问题。
如何做到:实现的功能覆盖了需求
要实现功能覆盖需求,需要团队不同角色的共同努力。如下图所示:
开发人员自测
开发人员自测指:开发人员开发完后,自己测试功能是否可以全部实现。如果产品经理有出验收标准,则需要对着标准跑一遍。对前端来说,自测的内容主要是:功能,UI 交互和浏览器兼容性。
开发自测很重要。一方面,程序员自测,能更早的发现问题。越早发现问题,修复问题花的成本越低。另一方面,开发人员自测是对自己代码质量负责,也是专业素质的体现。没自测就提交测试,也浪费 QA 的时间。
建议将自测这块体现到工作流工具中。如果你用的是 CODING,可配置任务流转规则:状态流转到测试中时,一定要填写自测的内容:
QA测试
QA 会对功能做全面深入的测试:不仅测试正常的流程功能,还会测试异常流程,异常值,边界值等。因此,QA测试是对功能实现检查中很重要的一环。
专业的 QA 都会设计测试用例。测试用例完整的覆盖需求。QA 测试通过,就是要通过所有的测试用例。
当然,QA 测试也存在局限性:如果开发过程中引入的缺陷不在当前测试功能的范围内,QA 很有可能发现不了。要缓解这种局限性,有 2 个建议:
- 开发在提交测试时,告知 QA 可能会影响的其他功能。
- QA 不管测试什么功能,测试完成后,都要再跑一遍产品所有模块最核心的测试用例。
产品经理验收
产品经理验收的是功能。产品经理对功能更敏感,容易发现漏做或实现的不对的功能。
设计师验收
设计师验收的是 UI 和交互。设计师有“像素眼”:能发现常人发现不了的 UI 问题。
仅仅实现了功能有什么问题
对于短期项目,仅仅实现功是没问题的。但现实中,很多是长期维护的项目。随着时间的推移,会加很多功能,也会改很多功能。项目会变得越来越大,越来越复杂。只管实现,不管代码的维护性。会加速的出现如下的问题:
- 增加新功能,改 bug 越来越难。花的时间也越来越长。
- 改了这个 bug,出现其他bug。
因此,对于长期项目,我们不仅要实现功能,还要注重代码的可维护性。我在下面的文章中会做详细介绍。
金伟强往期精彩文章推荐:《聊聊代码质量》