开发速度和代码质量,你的选择是?

jopen 7年前

开发速度和代码质量,你的选择是?

        英文原文:Velocity vs. Quality

        不得不承认,现在几乎每个软件开发项目都会不可避免地都会出现一个问题,那就是关于开发速度与代码质量该如何抉择。忽略一些细枝末节、偷工减料毫无疑问能让我们的项目进展地更快,所需时间更短。

        关于这个话题,几年来一直反反复复纠结在我的脑海里,我开始渐渐发现这个论题本身就是一个既危险又错误的悖论。也许重新规划这个论题能帮助我们达到一个共赢的局面:做出更好的产品、成就更优秀更有冲刺力的团队。

        当我们谈及产品质量的时候,往往包含测试覆盖率、变量命名法、代码格式化、组件化、界面设计、bug 情况、逻辑错误等众多指标。甚至有的时候,扩展能力、优化算法复杂度、服务延时、类库推广以及产品功能完整性方面也在考虑之中。

        为了使讨论更明确,区分不同的类别,我更喜欢将第一类的产品质量称为“代码质量”,而称第二类为“执行质量”或“深度”:执行的深度、完成的深度。

        偷工减料的代码质量可能短期内会有立竿见影的成效与收益,但是这只是水中月镜中花,在不久的将来需要我们连本带利地偿还:花大量的时间重构、花 大量的时间修复 bug、花大量的时间搞清楚究竟该如何才能使程序运作起来。因此,为了开发速度而牺牲代码质量其实就是作茧自缚,时间一到它就会像“高利贷“一样,利滚利 地让你付出更高的、甚至是高不可攀的代价:不得不推迟其他的工作、苦不堪言、悔不当初。

        良好的代码质量其实能让我们的进程跑得更快。保持一致的风格和带点提示的命名法能帮助其他人——还有将来的你——理解代码;干净又周密的接口能 让我们即使卸下或者更换整个组件,也不需要重新检查代码库的角角落落;良好的测试覆盖率能让我们在做改动时更有信心、能减少 bug 的数量、能使得 QA 时间最少化。

        随着时代的发展,现在的实施深度已经演变成另外一个问题。如今有很多方法可以在不降低产品整体质量的同时简化开发。

        项目实施本身并不需要是非常完美的,一开始我们只要保证功能具备即可。而在之后的某个阶段,我们可以再慢慢改善或者完全用新的内容取而代之。

        例如,在一个新的 app 里,其 RPC 层起初可能只是简单地做了一个 HTTP 类库。这样我们就可以把省下来的时间用到迭代应用层,以及那些还不够精致需要再接再厉的内容上。然后在未来的某个时间点——也有可能是当我们正准备发布的 那一瞬间——突然觉得这些个 RPC 层需要更为迷人;或者是应该添加重试逻辑、异常处理、安全功能甚至是改变传输协议,没错,即便是在这样的情况下去完善 RPC 层也完全 ok。

        在建设项目时,我们常常会历尽千辛万苦、呕心沥血、废寝忘食,不断地经历开发、重新开发、删除功能这个循环,最终导致大约 6 万行代码胎死腹中,不出现在预览版上。

        如果我们忽视代码质量,后期要想维护和扩展就会困难重重,并且产生大量的冗余代码。如果我们不能针对性地进行优化,事半功倍做出来的成果最终也跳脱不了记载于 Git 日志里而被静静遗忘在角落里的命运。

        事实上,现如今我们不但有能力给一些多余内容减肥,迅速给产品瘦身,还能在大多数情况下依旧保持其成为迭代和实验的良好基础。

        所以,要是下次有人再问你,“如果不关注代码的质量,能不能工作得更快?”的时候,理直气壮气地告诉他,“你问了一个愚蠢的问题!”

        译文链接:http://news.html5tricks.com/velocity-vs-quality.html
        翻译作者:IT 新闻 – 蒋丽丽