《Clean Code》实战经验总结

自从开始学《Clean Code》后，现在写代码都会遵循书中提到的观点，并在之上加以改进，主要以怎么样能让读者更快的理解完你的代码为主去考虑。下面就是我实战时总结的一些值得注意的地方

由于想到应该总结实战中体会到的地方的时候有点晚，有些之前体会到的观点猛地一下想不起来，所以就先写能记起的地方，其它的以后再补上去

——–思想这东西，想不起来就不见得你忘了，当你碰到对应的情况就会一下子git到解决办法，就好像key-value一样。哈哈

定义你自己的代码阅读等级范围

我觉得有必要明确下经常读你代码的人他们的水平在什么程度，这样我们就可以明确我们的Clean 究竟要Clean到什么程度。

就拿命名来说，如果想让代码更易读有时候我们就需要写的名字很长，这样会相对更费时间。但是究竟要写多长的名字合适呢？你可能会说写的能表述清楚意思而且越简单越好。但是这样式很不明确的回答，有的方法就是会比较难解释。

如果读你代码的人是经验比较丰富的，那么你的某个命名可以更简单一点（但是不要让属于你定义的等级范围内的人还需要花时间去琢磨），如果读你代码的人是一个新手，那么你就需要写的更明确一点了。

以下是一个简单的例子，只是表述下我的观点，不是多么标准的例子，大家见谅哈。

private BlockingQueue<ResultT> getResultQueueWhenNotExistReturnNull(ResultT value) {
}

上面这个方法名，有的人当读到这里，结合上下文代码，很快就可以理解到是从cacheResult中获取值（这个是这个类的成员变量）。

但是有的人可能会向下面这样写才能很快的了解到 ：

private BlockingQueue<ResultT> getResultQueueFromCacheResultWhenNotExistReturnNull(ResultT value) {
}

这个例子可能说明的不太准确，我只是表述下我的想法，大家意到即可哈。

写代码时先实现基本的方法，之后再在基本方法内部抽出代码重构为方法

写代码时不要急着去将方法划分成一个一个的小方法，而是待写完一个基本方法再进行重构，这样做的理由如下：
1. 如果实现一个方法的过程中，将其同时拆分成一个一个小方法，这样不利于自己总览思路，方法整合性太差，不便于集中逻辑。
2. 自己写的代码时肯定能非常明确的指导那一部分的具体意义，将所有的代码集合在一起反而更容易整理思路。
3. 通过IDEA我们可以很方便的对方法进行重构，这种情况下省去了我们写参数、返回值类型的时间，一般只要写好方法名就可以。

当然这不是说我们可以不划分方法了，我们要划分基本的方法，尽量让更多的逻辑居中到一块儿。（“基本” 的这个度要结合自身去定义）

当一个类中有多个要实现的方法时，尽量在最后方法都实现了再去重构

首先说下这样做的好处，当一个类的方法都写完后，你就可以以整体的角度去审查代码，这时候可能会发现两个同等级的方法内可能存在相似的代码，这个时候你就可以把它们抽出来，重构成方法。

下面是我的体会到的一个例子：

这两个方法是我实现接口时要实现的方法

  @Override
  public boolean remove(ResultT value) {
  }
  @Override
  public void add(ResultT value) {
  }

我首先写好了remove方法，之后对remove方法进行重构,重构完如下

    @Override
    public boolean remove(ResultT value) {
        removeResultFromCacheResultIfExist(value);
        return searchModel.remove(value);
    }

    private void removeResultFromCacheResultIfExist(ResultT value) {
        KeySearchT keySearch = mapWhatGetKeySearchByHasSavedResult.get(value);
        if (isExistKeySearch(keySearch)) {
            tryRemove(keySearch, value);
        }
    }

    private boolean isExistKeySearch(KeySearchT keySearch) {
        return keySearch != null;
    }

    private void tryRemove(KeySearchT keySearch, ResultT value) {
        BlockingQueue<ResultT> resultBlockingQueue = cacheResults.getCacheIfExist(keySearch);
        if (isHadAnyValue(resultBlockingQueue)) {
            resultBlockingQueue.remove(value);
        }
    }

    private boolean isHadAnyValue(BlockingQueue<ResultT> resultBlockingQueue) {
        return resultBlockingQueue != null && resultBlockingQueue.size() != 0;
    }

待我重构完了，实现add方法时才发现，add方法中刚开始的逻辑跟remove方法内的都是一样的，但是现在要在重构后的remove方法中抽出代码已经较为麻烦了，因为方法已经一层嵌套一层了。

注意不要隔夜或者隔时间过长再去重构写好的方法，最好在整体完工后就重构，否则可能会不清楚代码里面的逻辑，或者不清楚不同方法之间那些是重复的代码了

不要死记某一个观点或者总结的经验

我认为基本上没有什么观点适合所有情况的，总会有一些特殊的情况，我们采取我们所已知的规则之外的规则可能会更好或者打破原有的规则。

就拿上面这两条经验来说，并不是什么时候都要放在方法写完之后再去重构就最好的，有时候你在实现一个基础方法时，你会发现里面的有一些功能非常适合抽出为一个方法，它可能会让你的逻辑更加清晰，亦可能这个抽出的方法非常容易被其它代码使用。

这个时候如果你放在最后重构，可能这个想要抽出的方法已经和别的逻辑掺杂在一块儿了，这样会浪费时间。

所以无论什么情况下，无论遇到什么事情，我们都要更灵活的去考虑问题。让我们的生活更美好。哈哈

实现了较复杂逻辑的代码一定要多Code Review

当我们实现了某些较为复杂的逻辑代码，一定要有时间多Code Review，因为你第一次实现往往不是最佳的实现方案，其中总会存在一些缺陷或不足，通过Code Review会让你的代码升华。

不要定义过长的类名

我认为在定义一个类名时候没有必要写的过长，我们可以在类的代码开头加上精简的注释，同时在使用类的时候命名时说明它的功能。如果类名过长会给人一种很难受的感觉。

持续总结中，未完待续。。。。