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