降低团队效率

糟糕代码的一个很好的定义是缺乏帮助其他开发者理解其功能的技术实践的代码。

当你独自编码时，问题并不大。糟糕的代码只会让你慢下来，有时会让你感到有点沮丧。它不会影响其他人。然而，大多数专业人士是在开发团队中编码的，这完全是另一回事。糟糕的代码真的会拖慢整个团队的进度。

以下两项研究在这方面非常有趣：

第一项研究表明，开发者浪费了高达 23% 的时间在糟糕代码上。第二项研究表明，在 25% 的情况下，开发者在处理糟糕代码时被迫进一步增加糟糕代码的数量。在这两项研究中，使用了 技术债务 这一术语，而不是直接称为糟糕代码。这两个术语在意图上有所不同。技术债务是指为了满足截止日期而发布的具有已知技术缺陷的代码。它被跟踪和管理，并计划在未来替换。糟糕代码可能具有相同的缺陷，但它缺乏技术债务的 “有意为之” 这一优点。

我们很容易提交那些编写起来容易但阅读起来困难的代码。当我这样做时，我实际上是在向团队征税。下一个拉取我更改的开发者将不得不弄清楚他们到底需要做什么，而我的糟糕代码会让这件事变得更加困难。

我们都经历过这种情况。我们开始一项工作，下载最新的代码，然后盯着屏幕发呆很久。我们看到毫无意义的变量名，混杂在难以理解的复杂代码中。这对我们个人来说是令人沮丧的，但在编程业务中，它也有实际的成本。我们每花一分钟不理解代码，就意味着公司在这一分钟内为我们支付了工资，而我们却一无所获。这不是我们当初成为开发者时梦想的情景。

糟糕的代码会扰乱每一个未来需要阅读代码的开发者，甚至包括我们这些原始作者。我们会忘记自己之前的意图。糟糕的代码意味着开发者花费更多时间修复错误，而不是增加价值。它意味着更多时间被浪费在修复本应轻易避免的生产环境中的错误上。

更糟糕的是，这个问题会不断加剧。它就像银行贷款的利息。如果我们留下糟糕的代码，下一个功能将涉及为糟糕的代码添加变通方案。你可能会看到额外的条件语句出现，使代码有更多的执行路径，并为错误创造更多的藏身之处。未来的功能将建立在原始糟糕代码及其所有变通方案之上。它创建的代码中，我们阅读的大部分内容只是在解决最初从未正常运行的问题。

这种代码会耗尽开发者的动力。团队开始花费更多时间解决问题，而不是为代码增加价值。这对典型的开发者来说并不有趣，对团队中的任何人来说都不有趣。

项目经理失去了对项目状态的掌控。利益相关者对团队的交付能力失去信心。成本超支。截止日期推迟。功能被悄悄削减，只是为了在时间表上争取一点余地。新开发者的入职变得痛苦，甚至尴尬，尤其是当他们看到糟糕的代码时。

糟糕的代码使整个团队无法发挥他们的潜力。这反过来也不会让开发团队感到快乐。除了让开发者不快乐之外，它还会对业务成果产生负面影响。让我们来理解这些后果。