最好的代码是没有代码
2015 年 9 月 2 日
不久前,我开始着手清理一个接手过来的项目。因为项目有一些 bug,所以我有足够的自由来重构它。但修复旧 bug 会引入新 bug,于是乎我就陷入了恶性循环。
一整个周末,我都一头扎进源代码里,很快就发现了问题:这个项目太混乱了,乱成一锅粥。项目中有有很多不必要的、冗余的和紧密耦合的代码。我所说的混乱,并不是指代码看起来很业余或充斥着快代码(捷径代码)。事实上恰恰相反,项目里有太多“魔法”,我看到了很多聪明而宏伟的设计技巧,但它们与项目要解决的问题毫无关系。像反射、面向切面编程、自定义注解一个都不少。这个项目是一只被过度设计的怪兽。经过我的一番重构,模块规模减少到原来的一半不到。
我相信原先开发这个项目的人的出发点是好的,但聪明反被聪明误,他们使用的技巧给自己带来了麻烦。所以他们只得花很多时间在维护和修复 bug 上,而用户对满是 bug 的软件也会感到不满。开发者自己感觉就更糟糕,因为每个人都在抱怨这个项目。但是谁该为他们承受的这些痛苦负责呢?他们不得不花很长时间来修复 bug,却无法从工作中获得满足感。除了开发者自己,还能责怪谁呢!Jeff Atwood 在一篇博文中提到过:“最好的代码是没有代码”:
对于大多数软件开发者来说,要让他们承认这一点是很痛苦的,因为他们爱他们的代码。你写的每一行新代码都需要经过调试,需要具备可阅读性和可维护性。每次写新代码时,你都要在这种压力之下不情愿地这么做,而你已经无计可施了,不得不这么做。代码成了我们的敌人,因为有太多程序员写了太多该死的代码。如果你一定要写代码,那最好一开始就简洁。
Jeff 的观点很有道理。作为开发者,我们喜欢想出各种聪明的解决方案,认为这会让我们看起来更专业,或者有助于我们学习新的工具或技术。于是我们抛弃简单,层层叠加各种方案,并证明它们是“实际需要的”。但我们必须认识到,我们写的代码越多,在代码中使用的“魔法”也越多,为 bug 留下的机会也就越多。
这些 bug 会回头过来给我们或接手我们代码的人造成困扰,我们需要加班来修复它们。显然,我们不是在讨论如何使用技巧来减少代码行数。相反,我们应该问问自己是否需要写这么多代码。在我的职业生涯中,我见过一些自己开发的 ORM 框架和线程池,这让我想起了一句话:
不要重复发明轮子。
这句话不只是想想而已。在开发这些框架之前请先思考一下是否真的有必要。我参与过的一个项目使用 Hibernate 和 DAO/DTO 来执行一个简单的查询。另一个项目有一个事件处理系统,它使用反射 API 根据事件类型来调用具体的类方法。这个解决方案看起来很“巧妙”,我花了很长时间才搞清楚 IDE 标记未被使用的方法原来是通过反射来调用的。更搞笑的是,这个系统只处理一种类型的事件。实际上,这些代码可以被压缩成一个简单的 if 语句:
一整个周末,我都一头扎进源代码里,很快就发现了问题:这个项目太混乱了,乱成一锅粥。项目中有有很多不必要的、冗余的和紧密耦合的代码。我所说的混乱,并不是指代码看起来很业余或充斥着快代码(捷径代码)。事实上恰恰相反,项目里有太多“魔法”,我看到了很多聪明而宏伟的设计技巧,但它们与项目要解决的问题毫无关系。像反射、面向切面编程、自定义注解一个都不少。这个项目是一只被过度设计的怪兽。经过我的一番重构,模块规模减少到原来的一半不到。
我相信原先开发这个项目的人的出发点是好的,但聪明反被聪明误,他们使用的技巧给自己带来了麻烦。所以他们只得花很多时间在维护和修复 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 的一句名言结束本文:
如果你真的喜欢写代码,那就要喜欢到尽可能少写代码。