写给程序员：请你在必要时牺牲掉软件开发项目的速度

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

然而事实上，这个问题本身就是个伪命题。

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

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

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

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

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

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

所以如果我们起初没有小心处理代码质量的问题，最终一定会被查找各种很细微的问题困扰。如果我们没有完全聚焦在效果实现上，就一定会拖拖拉拉延后项目进度。

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

出品丨蓝海汇（ID:lanhaihui2015）
转载请联系授权