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

最近有这样一条热门微博：

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

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

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

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

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

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

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

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

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

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

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

分享到：