云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！
不久前，我开始着手清理一个接手过来的项目。因为项目有一些 bug，所以我有足够的自由来重构它。但修复旧 bug 会引入新 bug，于是乎我就陷入了恶性循环。
一整个周末，我都一头扎进源代码里，很快就发现了问题：这个项目太混乱了，乱成一锅粥。项目中有有很多不必要的、冗余的和紧密耦合的代码。我所说的混乱，并不是指代码看起来很业余或充斥着快代码（捷径代码）。事实上恰恰相反，项目里有太多“魔法”，我看到了很多聪明而宏伟的设计技巧，但它们与项目要解决的问题毫无关系。像反射、面向切面编程、自定义注解一个都不少。这个项目是一只被过度设计的怪兽。经过我的一番重构，模块规模减少到原来的一半不到。
我相信原先开发这个项目的人的出发点是好的，但聪明反被聪明误，他们使用的技巧给自己带来了麻烦。所以他们只得花很多时间在维护和修复 bug 上，而用户对满是 bug 的软件也会感到不满。开发者自己感觉就更糟糕，因为每个人都在抱怨这个项目。但是谁该为他们承受的这些痛苦负责呢？他们不得不花很长时间来修复 bug，却无法从工作中获得满足感。除了开发者自己，还能责怪谁呢！Jeff Atwood 在一篇博文中提到过：“最好的代码是没有代码”：
对于大多数软件开发者来说，要让他们承认这一点是很痛苦的，因为他们爱他们的代码。你写的每一行新代码都需要经过调试，需要具备可阅读性和可维护性。每次写新代码时，你都要在这种压力之下不情愿地这么做，而你已经无计可施了，不得不这么做。代码成了我们的敌人，因为有太多程序员写了太多该死的代码。如果你一定要写代码，那最好一开始就简洁。
Jeff 的观点很有道理。作为开发者，我们喜欢想出各种聪明的解决方案，认为这会让我们看起来更专业，或者有助于我们学习新的工具或技术。于是我们抛弃简单，层层叠加各种方案，并证明它们是“实际需要的”。但我们必须认识到，我们写的代码越多，在代码中使用的“魔法”也越多，为 bug 留下的机会也就越多。
这些 bug 会回头过来给我们或接手我们代码的人造成困扰，我们需要加班来修复它们。显然，我们不是在讨论如何使用技巧来减少代码行数。相反，我们应该问问自己是否需要写这么多代码。在我的职业生涯中，我见过一些自己开发的 ORM 框架和线程池，这让我想起了一句话：
不要重复发明轮子。
这句话不只是想想而已。在开发这些框架之前请先思考一下是否真的有必要。我参与过的一个项目使用 Hibernate 和 DAO/DTO 来执行一个简单的查询。另一个项目有一个事件处理系统，它使用反射 API 根据事件类型来调用具体的类方法。这个解决方案看起来很“巧妙”，我花了很长时间才搞清楚 IDE 标记未被使用的方法原来是通过反射来调用的。更搞笑的是，这个系统只处理一种类型的事件。实际上，这些代码可以被压缩成一个简单的 if 语句：
最好的代码是没有代码，而最快的代码是永远不会被执行的代码。我们的目标应该是让解决方案尽可能保持简单，避免过度工程，避免使用讨巧的技巧和设计模式，除非它们对于解决问题来说是绝对有必要的。复杂性是我们最大的敌人，不必要的复杂性更是如此。大多数时候，我们不需要这些复杂性。
最后，我以 Jeff 的一句名言结束本文：
如果你真的喜欢写代码，那就要喜欢到尽可能少写代码。
【云栖号在线课堂】每天都有产品技术专家分享！
课程地址：https://yqh.aliyun.com/zhibo立即加入社群，与专家面对面，及时了解课程最新动态！
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK
原文发布时间：2020-03-24
本文作者：Umer Mansoor
本文来自：“InfoQ 微信公众号”，了解相关信息可以关注“InfoQ ”
