项目开发：速度 vs. 质量

5顶
0踩

2013-05-09 17:04 by 副主编 WnouM 评论(6) 有13044人浏览

开发质量效率测试

本文作者系程序员Daniel F Pupius，这是一篇他发表在Medium上的博文，讲述自己怎么在实际写代码的过程中，发现在速度和质量间做出抉择其实是个伪命题。

程序开发项目进行过程中，通常会冒出这样的困惑：应该选择效率，还是选择质量？很多程序员都会有偷懒的思维，觉得把一些摸不清头绪、不知道怎么写的代码片段去掉，可以节省很多时间，更早完成项目计划。

其实过去几年中，我也是这么想的，但最近我开始意识到，这个问题的纠结之处不在于选择困难，而在于问题本身是个伪命题。

什么是“质量”呢？一般程序员说到“质量”二字时，他们说的有可能是测试通过率、变量命名、代码格式化、组件化、查找 bug、程序测试等等。也有可能是程序的可拓展性、服务延时、产品功能的完整程度。

问题往往就产生于以上两者被统一看待、不做区分的时候。其实前一种围绕代码的问题可以看成“代码质量”问题，第二种情况则可以看成“执行质量”，或者“执行程度”。

从“代码质量”上来看，程序员走捷径的偷懒思维，其实是种十分短视的做法。含糊绕过某个问题，你可能会一时觉得省事不少，但到头来，往往发现因此搅乱了系统而要花费更多的时间来一行行检查代码，找出 bug，甚至重新调整整体逻辑框架。所以牺牲代码质量换取速度通常是得不偿失的做法。

相反地，高质量的代码其实是可以帮助你节省时间的。统一的代码规范和变量命名，不仅可以帮到别的程序员，还可以帮到未来的你，更好地理解你现在写下的代码；经过严密思考而设计出的轻量级代码架构，则可以让你在迭代产品的时候获得更高的效率，更清晰地了解该从何处入手，而不是到数据库里漫天寻找需要替代的地方；而高测试通过率还可以给你充足的自信去调整产品，减少 bug 数量，最小化 QA 时间。

至于“执行质量”，这又是另一个命题。有很多方式可以在不降低产品质量的情况下，使得产品开发过程很紧凑。比如你可以先推迟一些不那么着急的工作，等到整体执行优化、系统稳健性做好的时候，再来做那些被暂时搁置的事情。

具体的做法就是，先把最终想要的产品效果定好，然后往其中填充内容不断修改，至于一些无关的细节可以最后再来优化。举例来说，刚开始开发产品时，可以用 RPC 来简化应用开发的流程，绕过复杂的协议传输问题，先在产品应用层面上快速迭代，随后再替换掉 RPC，加入重试、错误控制、安全检验等代码，或者干脆替换掉传输协议。

写 Medium 代码的时候，我们就是先实现效果，再调整细化部分的，最后删掉了很多无法整合进原先设定好的框架中的功能，大约是六万行代码左右。

所以如果我们起初没有小心处理代码质量的问题，最终一定会被查找各种很细微的问题困扰。如果我们没有完全聚焦在效果实现上，就一定会拖拖拉拉延后项目进度。但如你所见，很幸运我们前期工作做得充分，所以现在产品可以迭代得很快，并不断试验新功能。

其实在互联网领域中，不仅程序员会面临上述问题，很多产品经理也会为项目进度和质量打架的问题烦扰。所以 Daniel 的博文提供了一个很好的思考角度，或许下一次再有人问你是不是可以牺牲一点代码质量来追赶进度的时候，你就可以告诉他们：你问的是个伪命题。

Via medium.com & 36氪

查看图片附件

来自: 36氪

分享到：

5
顶

0
踩

评论共 6 条请登录后发表评论

6 楼 lynen 2013-05-14 09:51

这里把质量的范围缩小了，比如：对于一个功能性为主的系统或者是产品，在速度与质量衡量的时候就可以暂时把体验性或者是显示的漂亮性放在速度之后。“速度和质量间做出抉择其实是个伪命题”，这个结论有待商榷。

5 楼 ywbrj042 2013-05-14 09:01

这是个意识问题，我觉得中国大多数开发人员都有错误的认识，应该将质量视为贡献和职业操守，作为一个专业的技术人员的底线，不容被侵犯，一定要坚守质量底线。进度和限制时间不可变，那就变范围，我绝对对于互联网产品，范围一般都是可以变化的，用户真正用的时候能用到的功能只有20%，或者对功能进行简化，以用户为中心。

4 楼 hunray 2013-05-13 18:42

当你身兼数职的时候，速度和质量都只能是传说。最后就是扛不住走人。唉。

3 楼 huaoguo 2013-05-13 10:07

效率=速度+质量，没有质量，何谈效率？

2 楼 taolei0628 2013-05-11 20:16

有几个程序没有bug呢？任何项目最求质量都是有限度的，并且根据实际情况评估标准也不一样，到头来还是要在中间选择个平衡，这不是个伪命题。

作者举的例子我都认同，但得出的结论值得商榷。

1 楼 afuer 2013-05-10 13:49

严重同意这个文章，就跟大家不愿意写单元测试用例是一样的。总觉得是浪费时间。但大家真的写了后发现，其实是可以提高开发效率的。

发表评论

您还没有登录,请您登录后再发表评论

5顶0踩