今天继续学习本书的提示十五：DRY——不要重复自己。
作者首先给出了DRY原则的定义：在一个系统中，每一处知识都必须单一、明确、权威地表达。接下来作者指出DRY 不限于编码，复制粘贴源码只是DRY中很小的一部分，更多的是针对你对知识和意图的复制。如果当有地方需要改变时，你发现你在多个地方以多种不同方式进行了变更，那么就违反了DRY原则。接着作者用一个打印的具体例子，分享了代码中的重复的情况。并用一个内部代码都一样的例子说明并非代码相同就一定是违反DRY原则的。最后，作者还举例了文档中、数据中、表征、内外API、数据源、开发人员之间的重复，说明这些都非常重要。
这一章看得我是深有体会，几乎作者说的每一种重复我都有遇到过。先说代码上的重复，这个最简单但也不简单。说他最简单是因为我们项目引入了PMD校验，如果你直接大段拷贝代码会直接报错提醒，但插件有时候也太绝对了，就像作者说的，并不是所有重复都违反了DRY原则，有些地方就是规则相同，需要重复，但是现在都一刀切了，不过问题也不是太大。说他不简单，是因为很多地方的重复不是简单的一致，而是有隐藏的关连，没有能够做到单一明确的表达，比如我们在切面中隐藏了用户和公司的关连，差点导致我做切换分公司的时候忘记还要去把AOP中缓存的用户Id清除。文档中的重复我也是有着亲身的体会，一开始写了一段复杂的逻辑，会想着去写一大段注释来说明一下，可是后来发现这段逻辑还需要经常改动，但是注释的内容却不想再改了。现在我觉得最好还是用代码自身来完成注释，划分好逻辑之间的层级结构，使用切当的命名，而不是通过大段冗长的文字注释，可以让想了解具体逻辑的人比较容易的入手。
其他内容的重复当然也很重要，但我最后还想谈一谈关于开发啊人员之间的重复。我们的代码并没有特别高深，我们的业务也不需要造火箭，但是一些或常见或罕见的轮子还是时常会使用到的。我很多时候都会苦于找不到恰当的方法来满足我的要求，只能自己又去造了一个轮子。比如有一次我需要把按照一个对象中的一些属性把数组分组，根本不知道我们系统中有什么轮子能够完成这件事，后来自己通过重写toString方法加上set完成以后，全文搜了一下，发现原来labs里面早就有了一模一样的方法，我能找到这个方法也只是巧合发现我们两个都用了网上找来的相同轮子。还有更多的例子甚至数不胜数，比如我们系统中n个时间相关的util，很多正则的表达式，更别提每个人自己熟悉的方法和包。有没有什么好方法可以让更多的人知道这些内容而避免造出更多重复的轮子？
网友评论