在过去的几十年里，软件开发行业中出现了一个流行术语——干净代码。在最初的时候，这个概念确实为我们带来了很多收益：代码可读性更高、维护性更强、问题处理更快。但是，如今随着我们探索软件开发的更深层次，也有越来越多的人认为，这个概念已经过时了。今天，我要告诉你们的是：再见，干净代码。
在这篇博客中，我将与你分享一些对于干净代码的新思考，以及我们应该如何看待这个过时的概念。我认为，这是一个需要重新审视、重新思考的时刻。
首先，让我们来看看什么是干净代码。其实，它并没有一个固定的定义，不同的人会根据自己的经验和观点得出不同的结论。但是，无论如何，它们都有一个共同点，那就是代码的可读性和易理解性。通常来说，干净代码应该遵循一些规则和原则，比如说：
1. 函数要短小精悍，不能超过 10 行。
2. 变量名要有意义，尽量不使用缩写。
3. 代码要有注释，但不能过多。
尽管这些规则看起来很合理，但它们并不总是适用于每个项目。我们必须认识到，没有一种标准可以适用于所有情况。事实上，这些规则在某些情况下可能会成为累赘，如果我们的代码过于注重这些规则，就可能会导致另一个问题：不再注重代码本身的实际含义。
再来看看我们常常被灌输的“格式化”代码的理念。毫无疑问这是一个重要的概念，但是格式化代码并不总是意味着减少代码的复杂性和提高代码的可读性。相反，我们过于强调格式化，可能会转移我们的注意力，不再关注代码的语义本身。我们的代码再规范化、格式化，它们本身的意义与使用却往往不够明朗。
那么，什么是更好的方案呢？在我看来，我们应该关注代码的实际意义，而非过于关注表象的“规范性”和“可读性”。我们应该为代码创造环境，让它们自然而然地变得易于理解和使用。这就意味着我们需要更多的自由度，去创造出真正合适的、有意义的代码环境。
这个时候，我要回到最开始的话题：再见，干净代码。我们不再需要遵循简单的规则来定义代码的干净程度，相反我们应该做到更多的自由度和创意性发挥。我们需要摆脱固有的思维模式，不再害怕创造不规范的代码。如果这些代码满足了特定的需求，那么我们应该为它们掌声喝彩，而不是怒斥并改造它们。
总结一下，过时的概念需要被重新看待和思考。干净代码这个概念，虽然在过去的几十年里带给我们了很多的益处，但随着我们对软件开发越来越深入的了解，它已经不再适用于所有的情况。我们应该现代化地思考我们的代码，并且承认，传统意义上的“干净代码”是对我们不利的阻碍。所以，我们应该拥抱创意性地创造出适合当前需求的代码。让我们一起摆脱过时的思维模式，向着更好的未来，迈进吧。
了解更多有趣的事情：https://blog.ds3783.com/