不得不承认，现在几乎每一个软件开发项目都不可避免地存在一个问题，那就是如何在开发速度和代码质量之间做出取舍。忽略一些小细节，偷工减料，无疑会让我们的项目进度更快，花费的时间更少。这个话题在我脑海里翻来覆去好多年了，我开始看到这个话题本身就是一个既危险又错误的悖论。或许重新规划这个话题可以帮助我们实现双赢：做出更好的产品，打造更好更冲刺的团队。当我们谈及产品质量时，往往包括测试覆盖率、变量命名、代码格式、组件化、界面设计、bug状态、逻辑错误等诸多指标。甚至有时候，扩展性、优化算法复杂度、服务延迟、类库提升、产品功能完整性等也要考虑。为了让讨论更清晰，区分不同的类别，我更愿意将第一类产品质量称为“代码质量”，将第二类称为“执行质量”或“深度”：执行深度，完成深度。偷工减料的代码质量可能在短期内有立竿见影的效果和收益，但这只是水中梦。在不久的将来，我们需要有息地回报：花大量时间重构，花大量时间修复错误，花大量时间弄清楚究竟如何让程序运行。因此，为了开发速度而牺牲代码质量，实际上是弄巧成拙。到时候就会像“高利贷”一样，让你付出更高的、甚至是高不可攀的代价：你不得不推迟其他的工作，苦不堪言，后悔莫及。良好的代码质量实际上可以使我们的流程运行得更快。一致的风格和暗示性的命名有助于其他人——以及你将来——理解代码；干净且经过深思熟虑的界面允许我们删除或替换整个组件而无需重新访问代码库良好的测试覆盖率可以使我们在进行更改时更有信心，可以减少错误数量，并可以最大限度地减少QA时间。随着时代的发展，现在的执行深度又演变成了另一个问题。今天有很多方法可以在不影响产品整体质量的情况下简化开发。项目本身的实现不需要非常完美，我们只需要保证一开始功能可用即可。而在后期，我们可以慢慢完善它，或者用新的内容完全替换它。例如，在一个新的应用程序中，它的RPC层最初可能只是一个HTTP类库。这样，我们就可以把节省下来的时间用来迭代应用层，那些不够细化，需要再接再厉的内容。然后在未来的某个时候——也许是在我们准备发布的时候——突然觉得这些RPC层需要更迷人一些；或者应该增加重试逻辑、异常处理、安全特性，甚至改变传输协议，是的，即使在这种情况下，改进RPC层也是完全可以的。在构建一个项目时，我们往往会经过千辛万苦、费心费力、废寝忘食，不断经历开发、重新开发、移除功能的循环，最终以约6万行代码胎死腹中而告终并且没有出现在预览版中。如果忽略了代码质量，后期维护和扩展都会很困难，会产生大量的冗余代码。如果不能有针对性地优化，事倍功半的结果最终会被记录在Git日志中，被悄悄遗忘在角落。事实上，现在我们不仅有能力丢掉一些冗余的内容，快速瘦身产品，而且在大多数情况下也能为迭代和实验留下良好的基础。所以，下次有人问你，“如果你不注意代码的质量，你能工作得更快吗？”，自信地告诉他，“你问了一个愚蠢的问题！”翻译链接：http://news.html5tricks.com/velocity-vs-quality.html英文原文：Velocityvs.Quality
