不久前，我开始着手清理一个接手过来的项目。因为项目有一些 bug，所以我有足够的自由来重构它。但修复旧 bug 会引入新 bug，于是乎我就陷入了恶性循环。

一整个周末，我都一头扎进源代码里，很快就发现了问题：这个项目太混乱了，乱成一锅粥。项目中有有很多不必要的、冗余的和紧密耦合的代码。我所说的混乱，并不是指代码看起来很业余或充斥着快代码（捷径代码）。事实上恰恰相反，项目里有太多“魔法”，我看到了很多聪明而宏伟的设计技巧，但它们与项目要解决的问题毫无关系。像反射、面向切面编程、自定义注解一个都不少。这个项目是一只被过度设计的怪兽。经过我的一番重构，模块规模减少到原来的一半不到。

我相信原先开发这个项目的人的出发点是好的，但聪明反被聪明误，他们使用的技巧给自己带来了麻烦。所以他们只得花很多时间在维护和修复 bug 上，而用户对满是 bug 的软件也会感到不满。开发者自己感觉就更糟糕，因为每个人都在抱怨这个项目。但是谁该为他们承受的这些痛苦负责呢？他们不得不花很长时间来修复 bug，却无法从工作中获得满足感。除了开发者自己，还能责怪谁呢！Jeff Atwood 在一篇博文中提到过：“最好的代码是没有代码”：

对于大多数软件开发者来说，要让他们承认这一点是很痛苦的，因为他们爱他们的代码。你写的每一行新代码都需要经过调试，需要具备可阅读性和可维护性。每次写新代码时，你都要在这种压力之下不情愿地这么做，而你已经无计可施了，不得不这么做。代码成了我们的敌人，因为有太多程序员写了太多该死的代码。如果你一定要写代码，那最好一开始就简洁。

Jeff 的观点很有道理。作为开发者，我们喜欢想出各种聪明的解决方案，认为这会让我们看起来更专业，或者有助于我们学习新的工具或技术。于是我们抛弃简单，层层叠加各种方案，并证明它们是“实际需要的”。但我们必须认识到，我们写的代码越多，在代码中使用的“魔法”也越多，为 bug 留下的机会也就越多。

这些 bug 会回头过来给我们或接手我们代码的人造成困扰，我们需要加班来修复它们。显然，我们不是在讨论如何使用技巧来减少代码行数。相反，我们应该问问自己是否需要写这么多代码。在我的职业生涯中，我见过一些自己开发的 ORM 框架和线程池，这让我想起了一句话：

不要重复发明轮子。

这句话不只是想想而已。在开发这些框架之前请先思考一下是否真的有必要。我参与过的一个项目使用 Hibernate 和 DAO/DTO 来执行一个简单的查询。另一个项目有一个事件处理系统，它使用反射 API 根据事件类型来调用具体的类方法。这个解决方案看起来很“巧妙”，我花了很长时间才搞清楚 IDE 标记未被使用的方法原来是通过反射来调用的。更搞笑的是，这个系统只处理一种类型的事件。实际上，这些代码可以被压缩成一个简单的 if 语句：

if (event.type == THE_ONE_TYPE_THIS_SYSTEM_CAN_HANDLE) {  process_the_event_and_return_result;}

最好的代码是没有代码，而最快的代码是永远不会被执行的代码。我们的目标应该是让解决方案尽可能保持简单，避免过度工程，避免使用讨巧的技巧和设计模式，除非它们对于解决问题来说是绝对有必要的。复杂性是我们最大的敌人，不必要的复杂性更是如此。大多数时候，我们不需要这些复杂性。

最后，我以 Jeff 的一句名言结束本文：

如果你真的喜欢写代码，那就要喜欢到尽可能少写代码。

关注我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书！