你所在的项目组肯定遇到过类似的操作，只是方法不同，尤其是祖传代码。一眼望去，可谓是八位仙人大显身手。大多数程序员也觉得团队开发应该保持编程习惯的一致性。但一般认识的一致性表现在宏观层面。比如数据库访问是叫DAO还是Mapper？虽然Repository团队有一些统一的标准，但是在编码的时候，没有人总是给你CR，所以要求没有那么严格。因此，我们可以体会到代码编写的百家争鸣。还是看几个具体的案例来体会吧！这段代码奇怪的命名可以帮助你理解目前的分发渠道：网站只在KindleOmni-channel上可用乍一看，你可能认为没有问题，但我会很好奇作者：WEBSITE和KINDLE_ONLY是什么意思？WEBSITE：该作品将仅在我们自己的网站上发布，KINDLE_ONLY：该作品将仅在Kindle电子书商店提供。都是说只能在一个频道发布吗？是啊，既然意思差不多，为什么不都叫XXX或者XXX_ONLY呢？(⊙o⊙)……好像是一样的。所以，大家看到了吧，应该有类似含义的代码一个一致的名字，就像很多团队都会把业务写到服务层，各种服务类的类名也是XXXService。不一致的名称通常具有不同的含义。例如，对于那些不是业务入口的业务组件，它们的名称会有所不同，更符合其特定的业务行为，例如BookSender：向翻译引擎发送作品。我猜想，这段代码的作者在给枚举值命名的时候，只是考虑了应该分别叫什么名字，而忽略了枚举值在整体上的地位。至此，重构思路很明确：方案不一致。现在一个系统要向另一个系统发送请求，就需要带上时间戳，把这个时间戳按照格式转换成String。主要用于传输，方便外部系统识别。方便开发调试。代码片段本身的实现很好，即使考虑到SimpleDateFormat类不是线程安全的，所以每次都会创建一个新的SimpleDateFormat对象。那为什么我还说它有问题呢？因为这种写法是Java8之前的，而我们使用的Java版本是Java8。现在这是一个Java8项目，完全可以使用Java8新的datetimeAPI。所以项目也同意所有的日期和时间类型都使用新的API。所以，这段代码本身的实现是没问题的，但是整体放在项目中，反而和其他部分不一致。使用新的API进行重构就足够了：一个项目应该对同一个问题有多种解决方案。没有统一的约定，成员会根据自己的习惯随机选择一个方案，导致方案不一致。再比如判断一个字符串是否为空或者空串。有Guava和ApacheCommonsLang，它们都可以做同样的事情。因此，程序员会根据自己的熟悉程度选择其中的一种来使用，从而导致代码不一致。这两个库是很多库的基础，往往是因为引入了其他库，相应的依赖才会出现在我们的代码中。所以，我们在项目中一定要约定好哪种方式是我们的标准方式，以防有单独的业务。代码不一致在翻译引擎中创建作品的代码：首先根据待处理作品的ID，获取已经审核通过的作品，然后发送HTTP请求在翻译引擎中创建作品。你能看出有什么问题吗？这些代码不是一个级别的！首先是获得认可的作品，这是一种商业行为。接下来的三行其实是在做一件事情，就是发送创作作品的请求。这三行代码：创建请求的参数是根据创建请求的参数最终发送请求的。三行代码共同完成请求发送创建工作，这件事情整体上就是一个完整的业务动作。所以这个功能有的是业务动作，有的是业务动作的细节。所以重构就是：区分不同层级的代码，基本功就是分离关注点。一旦排除了不同的关注点，就可以进一步构建代码。和前面拆分出来的方法一样，我们已经知道它的作用是发送创建作品的请求，本质上不属于这个业务类。因此，这部分也可以通过引入新模型来调整：
