这样的傻事,其实并不遥远

最近有这样一条热门微博

这样的傻事,其实并不遥远

这样的故事真是精彩。最后一句“我想那是我此生唯一写垃圾代码的心安理得的一次机会了”,我明白至少作者还是有追求的。

任何KPI要合理都是无比困难的,这里的故事看起来有些极端,但就是一个简单地拿“代码量”数据统计来量化绩效指标的办法。这样的恶果公司最终会自己承担。

我曾经在这篇文章里面谈到过,统计指标是有价值的,但是如果设置这些量化指标给程序员套限,则是违背客观规律的行为。我称它们为反软件、反人类的。

我所见到的量化的指标皆是如此。程序员本来就是在利用死板的代码和数据,创造一些工具,完成一些重复性和可以预期的劳动。现在呢,反过来用死板的统计指标来约束程序员……

就这这个引子,我不想说太多。只想列举一些事实。嘲笑那些傻事的时候,我们离它们其实也并不遥远。

  • 测试覆盖率低于某个值的时候触发构建失败。(“测试覆盖率”是软件行业一个出现弊远大于利的东西,它本身没有什么问题,就像“敏捷”本身没有什么问题一样,但是大部分人用的时候都在扯淡)
  • 某公司在软件方法学和最佳实践的会议上宣称,类不得超过100行。(这个指标可以引申,可以扩展,在我看来把这个数无论是定到多少都不足以确定代码的质量,长代码未必复杂难懂,而短代码未必优雅易维护)
  • 重复代码比率低于20%,圈复杂度低于15。
  • 任何代码改动必须撰写详尽的说明文档,经过严格的审批。(难道不应该吗?但是,结果就是,当遇到微小的问题,程序员会决定放弃修改,改改半分钟,写一个审批文档10分钟。这样的审批机制确实能减少严重错误的发生,但是缺少了对更高质量的追求,这又有何意义呢?通过粗暴的办法,让一支犯错的高效率团队,变成一支不犯大错但碌碌无为的低效率团队)
  • ……

后来我翻到了这个知乎原帖。但是这个原帖的题目是《除了「deadline 紧」以外,程序员还有什么借口可以让自己写出低质量的代码?》。这其实是另一个话题。

其实,deadline紧,是一个最常见的原因,我发现所谓的时间紧砍需求都是扯淡,时间紧砍掉的最后总是质量,设计的质量,代码的质量。

  • 再来回答这个话题,我体会很深的借口是“先做出来,以后在迭代中再慢慢优化。”这话很多情况下是对的,但是已经被滥用了,不会设计的人总说两句话,一句是这话,第二句是利用测试驱动开发来做好设计。还是那个意思,这二者本身没有问题,只是已经被滥用了,绝大部分情况下都是荒谬的。
  • 接着就是加班狗们。这本质和“deadline紧”是同一个原因。
  • 再有常用的理由就是害怕重构和重做引入新的bug,这就是为什么不鼓励犯错的团队不可能有伟大的进步。
  • 这是临时的方案,临时的脚本,临时的work around,临时的配置,临时的……也许确实正确,但也许几年以后,这些临时的代码还在工作,而原作者呢,还在继续写临时的代码。类似的说法还有“测试代码”、“调试代码”等等。
  • “工作的代码比完美的代码更重要。”没错,代码工作当然更重要,但这并不意味着代码质量不重要。代码工作只影响这个软件版本,代码质量却和好的设计和好的习惯密切相关,影响程序员手中以后的软件版本。

当我看到这些傻事的时候,这些低质量代码的时候,已经不大惊小怪了。我也做过这些傻事,无论何种原因。这大概是程序员成长的记录里面,不太值得夸耀的一面。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接《四火的唠叨》

分享到:

发表评论

电子邮件地址不会被公开。

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Preview on Feedage: