代码质量第 5 层 - 只是实现了功能

 

 

 

产品实现的功能是产品价值的体现形式。功能实现是基础。功能没有实现，其他方面做得再好也没有意义。那么，如何保证实现的功能覆盖了需求呢？

 

 

产品实现的功能是产品价值的体现形式。功能实现是基础。功能没有实现，其他方面做得再好也没有意义。

本文主要内容如下：

1. 如何做到：实现的功能覆盖了需求。
2. 仅仅实现了功能有什么问题。

如何做到：实现的功能覆盖了需求

要实现功能覆盖需求，需要团队不同角色的共同努力。如下图所示：

 

 

开发人员自测

开发人员自测指：开发人员开发完后，自己测试功能是否可以全部实现。如果产品经理有出验收标准，则需要对着标准跑一遍。对前端来说，自测的内容主要是：功能，UI 交互和浏览器兼容性。

开发自测很重要。一方面，程序员自测，能更早的发现问题。越早发现问题，修复问题花的成本越低。另一方面，开发人员自测是对自己代码质量负责，也是专业素质的体现。没自测就提交测试，也浪费 QA 的时间。

建议将自测这块体现到工作流工具中。如果你用的是 CODING，可配置任务流转规则：状态流转到测试中时，一定要填写自测的内容：

QA测试

QA 会对功能做全面深入的测试：不仅测试正常的流程功能，还会测试异常流程，异常值，边界值等。因此，QA测试是对功能实现检查中很重要的一环。

专业的 QA 都会设计测试用例。测试用例完整的覆盖需求。QA 测试通过，就是要通过所有的测试用例。

当然，QA 测试也存在局限性：如果开发过程中引入的缺陷不在当前测试功能的范围内，QA 很有可能发现不了。要缓解这种局限性，有 2 个建议：

1. 开发在提交测试时，告知 QA 可能会影响的其他功能。
2. QA 不管测试什么功能，测试完成后，都要再跑一遍产品所有模块最核心的测试用例。

产品经理验收

产品经理验收的是功能。产品经理对功能更敏感，容易发现漏做或实现的不对的功能。

设计师验收

设计师验收的是 UI 和交互。设计师有“像素眼”：能发现常人发现不了的 UI 问题。

仅仅实现了功能有什么问题

对于短期项目，仅仅实现功是没问题的。但现实中，很多是长期维护的项目。随着时间的推移，会加很多功能，也会改很多功能。项目会变得越来越大，越来越复杂。只管实现，不管代码的维护性。会加速的出现如下的问题：

1. 增加新功能，改 bug 越来越难。花的时间也越来越长。
2. 改了这个 bug，出现其他bug。

因此，对于长期项目，我们不仅要实现功能，还要注重代码的可维护性。我在下面的文章中会做详细介绍。

 

 

 金伟强往期精彩文章推荐：《聊聊代码质量》