干净的代码是否在拖累你？过度思考代码结构的危险

干净的代码是让开发者感到自己像专业人士的最初理念之一。然而，对于许多开发者来说，它可能不再是一个有用的指导原则，而会变成一个陷阱。这就是为什么你需要学会划定界限，并识别它什么时候开始对你不利。

你开始对所有事情过度设计

在某个时刻，许多开发者会越过一条无形的界限。他们不再编写代码来解决当下的问题，而是开始编写代码来解决所有可能的未来问题。

一个简单的函数突然需要三层抽象，“以防万一”。一个小功能变成了一个小型框架，因为它将来可能需要扩展。

考虑一个基本的使用场景，比如格式化日期以便显示。不是简单使用一个小工具函数，而是最终会有一个 DateFormatter 接口、一个 DefaultDateFormatter 实现、一个选择格式化器的工厂，以及用依赖注入将它们连接在一起。最初的问题：“把这个日期转成字符串”，现在被繁琐的程序所掩盖。

结果呢？代码在技术上很干净，但在实际使用中却很笨重。过度设计往往隐藏在良好的意图背后。有时这些担忧是合理的，但很多时候，它们只是猜测。而掺杂在架构中的猜测往往随着时间的推移会表现得很差。

具有讽刺意味的是，最干净的解决方案往往是最无聊的：直接、略微重复，并且在需求变化时容易删除。

它会让你陷入完美主义的瘫痪

简洁代码原则的目的是帮助你更快地工作。但如果过度使用，它们可能会适得其反，让你在写任何东西之前都犹豫不决。

你坐在那里重构技术上可运行的代码，但感觉还“不够干净”。变量名可以更好。这个函数做了两件事。那个条件判断感觉有点不对。所以你进行调整。然后又调整一次。然后你意识到，这次调整在其他地方又引入了另一个不完美。

一个非常常见的例子是早期的功能开发阶段。你正在实现一个新的端点或用户界面流程，在行为尚未验证之前，你已经在担心一个函数是否足够小，是否应该将某些东西拆分成多个类，或者使用单独的模块是否是一个好主意，等等。

与其获取反馈，你反而在打磨一个可能在与用户首次接触时就无法生存的想法。令人不舒服的事实是，大多数代码只有在被使用、被误用并经过几次修改后才会最终成型。干净的代码通常是迭代的结果，而不是开始时的必要条件。

它限制了你的创造力

当干净代码的规则变成硬性法则时，它们不仅会让你变慢，还会开始影响你看待问题的方式。

你不是在问，“让这个工作最简单的方法是什么？”，而是问，“结构这个最正确的方法是什么？”你的关注点从解决问题转向了满足清单。这在实验中经常出现。也许你想尝试一个快速的实验、一个奇怪的想法，或者一个一次性原型。

在我进入软件开发之前，我曾经做过相当多的竞赛编程。我注意到的一件事是，那里面根本不存在什么干净的代码。变量名让人无法辨认，宏和大型函数随处可见。

换句话说，就是打破所有干净代码的规则。这是因为目标是以最有效的方式解决挑战，而不是去美化你的代码。当你的大脑专注于解决方案时，真正的创造力才会开始涌现，许多好点子就这样诞生了。

发布有缺陷的代码比不发布完美的代码更好

这是这一切核心的不太令人舒服的事实。你可以写出职业生涯中最优雅、结构最完善、抽象最美的代码，但如果它从未离开你的本地机器，它创造的价值将为零。

没人使用的完美代码就等于不存在的代码。这就是对干净代码的过度追求真正造成伤害的地方。你不断告诉自己，再重构一次就发布吧；那个计算总和的函数依旧感觉很凌乱；如果有人看了你的代码并对其进行评价怎么办？

这样想法就保持私密。分支保持未合并。副项目保持未完成。

与此同时，现实世界并不奖励架构上的纯粹性；它奖励的是反馈。用户并不在意你的内部结构是否遵循 SOLID 原则。他们关心的是功能是否能解决他们的问题。而了解这一点的唯一方法就是发布一些东西。

许多伟大的产品都是从今天的干净代码标准来看会令人不适的代码开始的。早期版本充满了重复、大量冗长的方法和值得怀疑的决策。当时重要的不是代码的整洁，而是学习。这些团队发布了产品，观察了现实，然后才进行重构。

如果只有一件事情是不完美的已发布代码能做到，而完美的代码永远做不到的，那就是它会教你。它会告诉你哪些部分真正重要，哪些抽象有用，哪些巧妙的想法是徒劳的。干净的代码在经历了这种反馈循环之后才最有力量，而不是在此之前。

这并不意味着你应该交付垃圾代码或忽视质量。这意味着你应该把干净的代码视为一种工具，而不是道德标准。用它来改进已经证明有价值的代码，而不是用它来阻止创意的诞生。

干净的代码是一种技能。正确使用时，它让系统更容易理解和修改。盲目使用时，它会成为阻力，减缓进度，扼杀创造力，并延迟反馈。记住，目标是一个能够随着时间改进的可运行软件。