脏代码的优势（！）

讽刺

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

原文发布于我的博客网站。

对我来说，最重要的优势是我不需要定义它；😄 几乎所有写过程序的人都知道什么是脏代码；至于是否每个人都意识到这一点，那就是另一回事了。

互联网上充斥着各种编写代码的原则、规则、技巧、最佳实践和步骤指南。如今，几乎每个程序员都在谈论使用各自编程语言编写代码时应该遵循的某种技巧。然而，在使用这些技巧编写代码时，我们必须遵守大量的规则和最佳实践。最终，这限制了我们自由地编写代码，降低了我们的效率，导致我们无法按时交付项目，并带来远超任何真正程序员所能想象的痛苦。

以下是遵循此类做法可能产生的副作用的概要：

• 给东西命名要花很多时间。
• 模块之间不必要的分离
• 这导致我们编写大量额外的代码，而这些代码永远不会出现在产品版本中。
• 不允许添加评论
• 强迫人们先故意犯错，然后再解决它们。让我们更详细地了解这些副作用，看看它们有多么痛苦。

命名事物

网上很多人都在讨论给变量、函数、类、模块起有意义的名字以及这样做的必要性。但为什么这么必要呢？如果你把变量命名d为别的名字，会发生什么numberOfDaysInTrailPeriod？

int d = 10;
int numberOfDaysInTrailPeriod = 10;

编译器不会生成任何错误，运行时也不会出现任何问题。
同样地，

int rdsTrail(){//code}
int remainingDaysInTrailPeriod(){//code}

拜托，我们别浪费时间去想什么合适又有意义的名字了。

如果将来我们自己或其他人要使用这段代码，我们会进行调试并理解代码的内容int d及其int rdsTrail()含义。

模块解耦

这是编写包含多个相互交互模块的大型项目时，某些技术讨论中经常提及的另一个话题。编写模块接口时也会遇到这个问题。我不明白他们为什么要把实现隐藏在这些接口后面？他们称之为某种抽象。
好像没人会去修改这些实现似的。我们已经疲于应付实现新功能和修复 bug 了，为什么还要去修改别人的实现呢？
如果模块之间交互如此频繁且密集，为什么还要保持模块之间的严格隔离呢？我们为项目编写了模块，如果移除任何一个模块，整个项目就毫无用处。那么，为什么还要假设我们会单独且独立地使用每个模块呢？

如果将来我们需要替换任何模块，只需根据新模块修改相应的代码；或者如果需要在其他项目中重用，只需重写即可。

单元测试

这是程序员的另一个误区，他们总是花费更多的时间和精力去编写一些只需一分钟就能完成的简单代码。单元测试的主要目的是检验代码是否按预期运行，但如果我们有QA和测试人员在旁边，为什么还要自己费力测试代码呢？
单元测试不必要地强迫我们将原本庞大而复杂的函数拆分成更小的模块。限制函数的行数也会限制我们的编写速度。此外，我们为什么总是要遵循单一职责原则和自上而下的函数调用流程呢？这当然会降低我们的速度。

如果有人想在修改代码或添加更多代码后测试代码的运行情况，那么他/她只需将程序交给测试人员即可。

可读性

人们常说，代码应该写得既能让计算机理解，也能让人类理解。然而，如果我们真的要遵循这条规则，那就意味着我们要浪费时间编写一些其他程序员只需阅读就能轻松理解的代码。但话说回来，既然我们有了如此美观强大的集成开发环境（IDE），程序员为什么还要阅读代码，而不是直接运行并查看输出呢？
他们提出的另一个限制是代码中不能再添加注释。但所有IDE都支持在代码中添加注释。与其试图通过阅读代码来理解它，不如在需要的地方添加注释来解释。在上面的例子中，我们可以添加如下注释：

int d = 10; //number of days in trail period

这样做没有任何问题，编译器既不会报错，编译后的版本也不会包含这些注释。

如果我们担心代码的可读性，那就让他们通过调试、阅读控制台日志或者阅读注释来理解它。

测试驱动开发

现在我终于可以用“噩梦”这个词了！TDD 对所有程序员来说简直就是一场噩梦，尤其是对那些真正遵循它的人来说。犯错，改正；再犯错，再改正……这难道不荒谬吗？相信我，这种流程会生成一个比实际程序更大的并行程序，耗时也会翻倍以上。而它存在的意义仅仅在于强迫我们遵守上述所有规则。
即使是很小的修改，我们也需要先修改相应的测试；即使是添加一小段代码，我们也需要先编写测试。也就是说，我们必须先考虑测试，然后再考虑实现；这难道不浪费时间吗？

与其让测试驱动我们的开发，为什么我们不能直接开始，避免犯任何错误呢？

在最后

我想和你争论一下，不要被人们的说法所迷惑，而忽略我们代码的以下几个特性：

• 易于阅读和理解
• 易于更换的模块、算法
• 易于调试和修复错误
• 易于修改和重复使用
• 添加新功能很容易。将来如有需要，我们可以随时添加。所以，放松心情，编写能够正常运行的代码吧！

你知道我这篇博文的意思……！！！
（图片来源： rathod.milan053@gmail.com）
无论你是程序员、程序员还是其他任何一方，都请留言并点个赞！

参考资料：《鲍勃大叔的清洁代码》