英文原文：Velocity vs. Quality
不得不承认，现在几乎每个软件开发项目都会不可避免地都会出现一个问题，那就是关于开发速度与代码质量该如何抉择。忽略一些细枝末节、偷工减料毫无疑问能让我们的项目进展地更快，所需时间更短。
关于这个话题，几年来一直反反复复纠结在我的脑海里，我开始渐渐发现这个论题本身就是一个既危险又错误的悖论。也许重新规划这个论题能帮助我们达到一个共赢的局面：做出更好的产品、成就更优秀更有冲刺力的团队。
当我们谈及产品质量的时候，往往包含测试覆盖率、变量命名法、代码格式化、组件化、界面设计、bug 情况、逻辑错误等众多指标。甚至有的时候，扩展能力、优化算法复杂度、服务延时、类库推广以及产品功能完整性方面也在考虑之中。
为了使讨论更明确，区分不同的类别，我更喜欢将第一类的产品质量称为“代码质量”，而称第二类为“执行质量”或“深度”：执行的深度、完成的深度。
偷工减料的代码质量可能短期内会有立竿见影的成效与收益，但是这只是水中月镜中花，在不久的将来需要我们连本带利地偿还：花大量的时间重构、花大量的时间修复 bug、花大量的时间搞清楚究竟该如何才能使程序运作起来。因此，为了开发速度而牺牲代码质量其实就是作茧自缚，时间一到它就会像“高利贷“一样，利滚利地让你付出更高的、甚至是高不可攀的代价：不得不推迟其他的工作、苦不堪言、悔不当初。
良好的代码质量其实能让我们的进程跑得更快。保持一致的风格和带点提示的命名法能帮助其他人——还有将来的你——理解代码；干净又周密的接口能让我们即使卸下或者更换整个组件，也不需要重新检查代码库的角角落落；良好的测试覆盖率能让我们在做改动时更有信心、能减少 bug 的数量、能使得 QA 时间最少化。
随着时代的发展，现在的实施深度已经演变成另外一个问题。如今有很多方法可以在不降低产品整体质量的同时简化开发。
项目实施本身并不需要是非常完美的，一开始我们只要保证功能具备即可。而在之后的某个阶段，我们可以再慢慢改善或者完全用新的内容取而代之。
例如，在一个新的 app 里，其 RPC 层起初可能只是简单地做了一个 HTTP 类库。这样我们就可以把省下来的时间用到迭代应用层，以及那些还不够精致需要再接再厉的内容上。然后在未来的某个时间点——也有可能是当我们正准备发布的那一瞬间——突然觉得这些个 RPC 层需要更为迷人；或者是应该添加重试逻辑、异常处理、安全功能甚至是改变传输协议，没错，即便是在这样的情况下去完善 RPC 层也完全 ok。
在建设项目时，我们常常会历尽千辛万苦、呕心沥血、废寝忘食，不断地经历开发、重新开发、删除功能这个循环，最终导致大约 6 万行代码胎死腹中，不出现在预览版上。
如果我们忽视代码质量，后期要想维护和扩展就会困难重重，并且产生大量的冗余代码。如果我们不能针对性地进行优化，事半功倍做出来的成果最终也跳脱不了记载于 Git 日志里而被静静遗忘在角落里的命运。
事实上，现如今我们不但有能力给一些多余内容减肥，迅速给产品瘦身，还能在大多数情况下依旧保持其成为迭代和实验的良好基础。
所以，要是下次有人再问你，“如果不关注代码的质量，能不能工作得更快？”的时候，理直气壮气地告诉他，“你问了一个愚蠢的问题！”
译文链接：http://news.html5tricks.com/velocity-vs-quality.html
翻译作者：IT 新闻 – 蒋丽丽
相关文章
