其实过去几年中，我也是这么想的，但最近我开始意识到，这个问题的纠结之处不在于选择困难，而在于问题本身是个伪命题。
什么是“质量”呢？一般程序员说到“质量”二字时，他们说的有可能是测试通过率、变量命名、代码格式化、组件化、查找bug、程序测试等等。也有可能是程序的可拓展性、服务延时、产品功能的完整程度。
问题往往就产生于以上两者被统一看待、不做区分的时候。其实前一种围绕代码的问题可以看成“代码质量”问题，第二种情况则可以看成“执行质量”，或者“执行程度”。
从“代码质量”上来看，程序猿走捷径的偷懒思维，其实是种十分短视的做法。含糊绕过某个问题，你可能会一时觉得省事不少，但到头来，往往发现因此搅乱了 系统而要花费更多的时间来一行行检查代码，找出bug，甚至重新调整整体逻辑框架。所以牺牲代码质量换取速度通常是得不偿失的做法。
相反地，高质量的代码其实是可以帮助你节省时间的。统一的代码规范和变量命名，不仅可以帮到别的程序猿，还可以帮到未来的你，更好地理解你现在写下的代 码；经过严密思考而设计出的轻量级代码架构，则可以让你在迭代产品的时候获得更高的效率，更清晰地了解该从何处入手，而不是到数据库里漫天寻找需要替代的 地方；而高测试通过率还可以给你充足的自信去调整产品，减少bug数量，最小化QA时间。
至于“执行质量”，这又是另一个命题。有很多方式可以在不降低产品质量的情况下，使得产品开发过程很紧凑。比如你可以先推迟一些不那么着急的工作，等到整体执行优化、系统稳健性做好的时候，再来做那些被暂时搁置的事情。
具体的做法就是，先把最终想要的产品效果定好，然后往其中填充内容不断修改，至于一些无关的细节可以最后再来优化。举例来说，刚开始开发产品时，可以用 RPC来简化应用开发的流程，绕过复杂的协议传输问题，先在产品应用层面上快速迭代，随后再替换掉RPC，加入重试、错误控制、安全检验等代码，或者干脆 替换掉传输协议。
写Medium代码的时候，我们就是先实现效果，再调整细化部分的，最后删掉了很多无法整合进原先设定好的框架中的功能，大约是六万行代码左右。
所以如果我们起初没有小心处理代码质量的问题，最终一定会被查找各种很细微的问题困扰。如果我们没有完全聚焦在效果实现上，就一定会拖拖拉拉延后项目进度。但如你所见，很幸运我们前期工作做得充分，所以现在产品可以迭代得很快，并不断试验新功能。
其实在互联网领域中，不仅程序猿会面临上述问题，很多产品经理也会为项目进度和质量打架的问题烦扰。所以Daniel的博文提供了一个很好的思考角度，或许下一次再有人问你是不是可以牺牲一点代码质量来追赶进度的时候，你就可以告诉他们：你问的是个伪命题。
