设计原则之DRY 原则

设计原则之DRY 原则

  DRY（Don’t Repeat Yourself），翻译成中文就是，不要重复你自己。这个原则最早出现在经典著作《程序员修炼之道》里，定义是这样的：系统的每一个功能都应该有唯一的实现，如果多次遇到同样的问题，就应该抽象出一个共同的解决方法，而不要重复开发同样的功能代码。 但是对于DRY原则，会比较容易陷入如下的一些思维陷阱中：

陷阱一：随时关心代码重用性

代码重复通常有以下三种类型：
  1. 功能需求重复，比如，A 团队和 B 团队都做了在线文档管理功能、QQ 和微信的聊天通信功能等；
  2. 实现逻辑重复，比如，同一个文件上传功能，A 同学使用 Spring 框架实现，B 同学使用 JDK 原生功能实现；
  3. 执行调用重复，比如，登录页面查询用户信息前调用用户密码校验，查询用户信息时也调用用户密码校验。
  开发不要太过度的关注是否重复，更多得是需要考虑代码重复是否真的就是一个问题。对于代码重用性，可以坚持以下原则：先可用，后重用。你应该先写出可以运行的代码，再考虑是否需要重用代码。
  1. 如果还没有找到抽象的话，其实也没有关系，因为等到有更多的上下文时，还可以重构它。
  2. 要想不重复你自己，需要先不再随时关心代码重用性，保留适当的重复，等到真的重复时，再去抽象可复用的公共代码。

陷阱二：过度设计

我们总是期望通过现阶段的灵活设计来避免未来需求变化后的重复设计与编码。这样做确实特别符合 DRY 原则的理念。但实际上，需求的变化方向是不可预测的。一旦投入了过多的精力到灵活设计上，势必会影响本应该完成的需求。同时，过多的功能会引入更多潜在的问题，而修复问题也会耗费我们的时间和精力。

对于代码重用性，可以坚持以下原则：抓住上下文，适度设计。
  1. 代码设计的过程中，应该遵循有限范围的原则，也就是抓住上下文。比如，需要开发一个内部的数据管理后台的权限管理功能，那么要抓住的上下文就是数据是否敏感、使用人员的大致范围和人数、功能交付截止日期、团队现在使用的类库和框架、有没有采用基本的权限认证等，然后才开始进行设计与代码实现。
  2. 当搞清楚了基本的上下文后，才能开始适度设计并编码。“适度”虽然没有一个统一的标准，但有一个简单实用的方法：当你想要扩展通用设计时，想想一年后这个项目是不是还存在。

陷阱三：写一次性代码

如果教条式地理解 DRY 原则，很容易走入一种极端的应用场景：为了不重复而不重复，俗称写一次性代码。一次性代码主要包含以下两种场景：
  1. 硬编码，指的是将一些配置数据或通用信息写入代码中，导致信息一旦发生变动，就不得不修改代码来满足要求。比如说，将邮件发送程序中的用户名、密码和邮箱地址写入代码中，当密码发生变化时，维护代码的人就需要修改代码，重新编译打包。
  2. 复制粘贴编程，是指通过将他人已经实现的代码复制到自己的代码中实现同样的功能。这是现在最常用的编程方式之一，理由就是不重复造轮子。
这只是一种表面的不重复，写一次性代码不仅会导致频繁修改引入更多 Bug，还会导wei致架构无法及时演进累积更多的技术债，最终导致系统的庞大臃肿而难以理解。

对于这种情况，可以坚持以下原则：坚持写易懂的代码
   1.易懂的代码不是指容易、简单的代码。易懂的代码能借用语言特性来发挥优势。比如，在 Java 中利用驼峰大小写来区分不同方法的命名含义，或利用熟悉的 get、set、insert、update 等习惯命名，或使用 @Service 等特定注解来标识服务等。
  2.易懂的代码需要遵从一定的代码规范。 比如，接口定义加注释，MySQL 数据库中使用下划线来区隔字段名并备注含义，使用枚举定义状态值，if-else 的嵌套最多三层等。
  3.易懂的代码要能正确运行。 千万不要为了易懂而写大量的说明文档和注释，但却忘记了代码的正确运行逻辑。
  4.易懂的代码不是你告诉计算机怎么做的答案，而是告诉另一个程序员你想要计算机做什么的意图。

总结：

对于DRY原则，需要明白的是不要为了遵从设计原则而设计，并不是代码重复了就一定是坏的代码，不能以代码是否违反了DRY原则去判断重复代码的好坏。如果过分纠结于以不违反原则为代码的基本，就会掉入上述的思维陷阱中。宁可重复，也不能错误的对代码进行抽象。不能为了代码的抽象而创建抽象。
DRY原则很容易被人们误解为编程时就不应该存在重复的代码，但是DRY原则的真实意图并非如此。一切的原则都允许依托于具体的环境上下文中。在技术选型时，DRY原则可以帮助我们对于一些组件服用的本质以及功能实现时减少一些新奇想法的冲突，而不是仅仅的纠结于所编写的代码是否重复了。
DRY原则是最简单也是最被容易理解的，但是同时也是最难被应用的。DRY原则初衷是为了帮助我们提升代码的可重用性和复用性，可是很多人在使用时却为了不重复而引入了更多其他新的问题。
对于所有的原则，我们都需要保持对原则的警醒比代码中实际应用了多少原则更为重要。


参考:
拉钩教育-《趣学设计模式》第七讲