不管是做产品还是做项目，也不管是采用瀑布模型还是敏捷开发，我们都有一个终极目标，就是能按时交付质量可靠的功能，其中质量尤为重要。

本文是我对产品质量的一点思考，如果您所在的团队代码质量很高，很少出BUG，那么可以私信我，我们可以交流下关于代码质量的一些问题。

小公司面临的问题

大公司里每个人指责分明，团队的人员配置也比较齐全，有完整的开发流程，流程也会不断的迭代优化，每个环节只要按照流程严格去执行，基本不会出什么大的问题。但不是每个人都能够进入到大公司，或者说会一直待在大公司，如果您是在中小公司，可能会有下面一些情况：

• 没有专职的需求分析人员，没有专职的测试人员，很多时候是一岗多职

• 没有不急的项目，客户永远说的都是越快越好

• 虽然说唯一不变的就是变化，我们需要拥抱变化，但常常会即便拥有一双长臂，也无力拥抱

• 需求来了，直接写代码，后期补文档

• 代码中基本不写单元测试

• 没有自主研发的需求管理平台

为什么会有上面的问题，我觉得很重要的一个原因是成本问题，专职需求分析需要人力成本，写单元测试、文档等需要时间成本，等等。短期看来是节省了成本，但从长远来看，会导致质量下降，最终会得不偿失，如果您是做项目，打一枪换个地方，我不做评价，如果是在不断地迭代成品，那么就要停下来好好思考下了。

我们的现状

10人左右的团队，需要做的事情如下：

• 需求分析

• Vue前端开发

• dotNetCore后端开发

• H5、小程序、iOS、安卓

• 测试

• 运维

上面说到，在小公司会是一岗多职，我们也不例外，大概任务分配如下：

• 全员做需求分析，即便是新手，也要求做简单需求的分析

• 后端工程师除了iOS和安卓不做，其他的都做

• iOS和安卓工程师除了后端不做，其他都做

• 只有一两个只做纯前端的工程师

目前来看，整个团队是偏全栈的，全栈的团队理论上效率会很高，的确，效率从来都不是我担心的问题，但质量问题却一直都没能很好的解决：

• 开发人员还是更喜欢写代码，文档能力偏弱，虽然目前强制规定每个所做的需求在语雀上要写对应的需求文档，但很多时候写不到点子上，关联影响点也没有分析，给测试提供不了很好的支撑

• 文档写不好，加上开发者的思维，很多低级问题在自测阶段不能被发现

• 经常改了A模块的一个问题，引发其他模块的几个问题

• 同样的问题会反反复复出现

怎样解决质量问题

取舍和平衡

我认为软件开发其实是在时间、范围、稳定性和代码质量上做博弈：

• 时间：交付一个功能的期限，比如老板说3个月要上线某功能

• 范围：需要实现功能的边界

• 稳定性：随着版本的不断更新，用户使用产品的一个最直观的感受

• 代码质量：代码是否是可复用，易于维护的，用户不能直观感受，但也同样重要

领导总是会说，这个时间节点非常重要，或者重要客户，不能延后，等等，总之时间节点后延的可能性不大。

稳定性也不能出问题，轻则客户满意度降低，重则会造成事故，给客户带来严重损失，客户可能因此就丢了。

所以只能在范围和代码质量上做取舍：

• 本来应该三个月做的任务，非要压缩到一个月，那只能去和领导沟通，将一些不重要，或者不紧急的任务放到下一阶段完成

• 如果范围也不能压缩，那就只能舍弃代码质量了，怎么快怎么来，但也因此欠下了一个技术债，债是需要偿还的，也是有利息的，还的越迟，利息越多。

自动化测试

自动化测试分为两个部分，构建之前的单元测试和构建之后的端到端测试

• 单元测试又分为前端Vue的单元测试和dotNetCore的单元测试，在一个已成型的产品中去加单元测试是很困难的，所以只能先找一些关键点，经常出问题的点去尝试

• 端到端的测试我们采用TestCafe，反复出问题的地方，就提炼出来一种业务场景，有针对性地去写测试代码

配合Jenkins，做到测试的自动化，那是不是有了自动化测试就能高枕无忧了呢？并不是，我觉得更重要的是，每个人员对产品要有深入的理解，对所做的需求要能完全掌握，对关联影响点的分析要没有任务遗漏。

测试只是手段而不是目的，我们的目的是写出好的代码，交付出无缺陷的功能。

总结

没有任何的方法论是可以生搬硬套的，只有不断的去学习、吸收、结合现有资源进行实践、不断的重复这个过程，直到找到一种适合自己团队的落地方案。

改善质量的道路任重而道远，不断地去尝试，去实践总会有些效果的。

您所在的团队又是怎么样来保证质量的呢？欢迎讨论。