Putting your context at a higher level

代码模块化的目的是让代码组织职责清晰,方便复用。
如果跳出这个场景,放到更广泛的领域会如何呢?比如设计、文档、组织架构 ……

DRY(Don’t Repeat Yourself) 原则在代码层面的理解是,多次遇到同样的问题,应该抽象出一个共同的解决方法,不要重复开发同样的功能避免代码重复。
今天看 《程序员修炼之道 第2版》知道不要复制代码只是 DRY 中很小的一部分。DRY 针对的是 知识意图 复制的约束,强调的是不要重复表达相同的东西,但表达方式有可能完全不同。这样运用 DRY 原则,明显层次更高,运用范围更广了。
看起来太抽象,举些例子:

  1. 验证 IP 有效性在代码中出现了两种实现方式,一种用正则表达式实现,还有一种用 Java 自带的类库 InetAddress 通过异常校验。两种方式代码完全不同,但是意图是一样的,这样也算是违反了 DRY 原则
  2. 业务要求用户名和密码都不能超过16位,且不能出现特殊符号。代码分别实现了 isValidUsernameisValidPassword 两个函数,单函数实现代码完全相同。这里不能说是违反了 DRY 原则,因为两个函数所表达的语意是不同的,后面很有肯能随着业务变化,用户名和密码的约束规则发生不一样。
  3. 校验用户登录的函数 login(String email, String password) 调用了 isValidEmail(email)isUserExisted(email), isUserExisted(email) 在实现时也调用了 isValidEmail(email) ,在代码实现上看没有违反 DRY,但是当执行 login 函数时会执行两遍 isValidEmail ,这种情况也是违反了 DRY 原则。
  4. 实现 isValidEmail(email) 的函数上写了一堆注释,把函数的校验逻辑通过文字的方式又描述了一遍,这也违反了 DRY 原则,属于 知识 的重复。
  5. 一份数据多处保存的重复,也是违反 DRY 原则
  6. 开发人员之间在实现业务功能时,可能出现的相同功能被多次实现,一份数据多处保存的问题,需要建立良好的沟通机制和代码审查机制来尽量避免。

我们在某个领域使用某个技术时候,要习惯跳出当前的上下文,站在更高的层次、不同的角度思考,可能会有更深入的理解、更广泛的运用,还有可能能把一个特定领域的技术通用化。