Putting your context at a higher level
一
代码模块化的目的是让代码组织职责清晰,方便复用。
如果跳出这个场景,放到更广泛的领域会如何呢?比如设计、文档、组织架构 ……
二
DRY
(Don’t Repeat Yourself) 原则在代码层面的理解是,多次遇到同样的问题,应该抽象出一个共同的解决方法,不要重复开发同样的功能避免代码重复。
今天看 《程序员修炼之道 第2版》知道不要复制代码只是 DRY
中很小的一部分。DRY
针对的是 知识
和 意图
复制的约束,强调的是不要重复表达相同的东西,但表达方式有可能完全不同。这样运用 DRY
原则,明显层次更高,运用范围更广了。
看起来太抽象,举些例子:
- 验证 IP 有效性在代码中出现了两种实现方式,一种用正则表达式实现,还有一种用 Java 自带的类库
InetAddress
通过异常校验。两种方式代码完全不同,但是意图是一样的,这样也算是违反了DRY
原则 - 业务要求用户名和密码都不能超过16位,且不能出现特殊符号。代码分别实现了
isValidUsername
和isValidPassword
两个函数,单函数实现代码完全相同。这里不能说是违反了DRY
原则,因为两个函数所表达的语意是不同的,后面很有肯能随着业务变化,用户名和密码的约束规则发生不一样。 - 校验用户登录的函数
login(String email, String password)
调用了isValidEmail(email)
和isUserExisted(email)
,isUserExisted(email)
在实现时也调用了isValidEmail(email)
,在代码实现上看没有违反DRY
,但是当执行login
函数时会执行两遍isValidEmail
,这种情况也是违反了DRY
原则。 - 实现
isValidEmail(email)
的函数上写了一堆注释,把函数的校验逻辑通过文字的方式又描述了一遍,这也违反了DRY
原则,属于知识
的重复。 - 一份数据多处保存的重复,也是违反
DRY
原则 - 开发人员之间在实现业务功能时,可能出现的相同功能被多次实现,一份数据多处保存的问题,需要建立良好的沟通机制和代码审查机制来尽量避免。
三
我们在某个领域使用某个技术时候,要习惯跳出当前的上下文,站在更高的层次、不同的角度思考,可能会有更深入的理解、更广泛的运用,还有可能能把一个特定领域的技术通用化。