<clean code>学习笔记

 

 

有意义的命名

 

1.名副其实，体现本意。

int d; //时间，天计算

int elapsedTimeIndDays;

 

 

2.言简意赅，避免废话的命名

比如Product，还有一个ProductInfo或者ProductData。区别何在？ 比如下面这个方法:

 

getActiveAccount();

getActiveAccountInfo();

程序员应该调用哪个方法？

 

 

3.类名应该是名词或者名称短语，如Customer,VikiPage,Account,AddressPaser。避免使用Manager,Processor,Data这样的类名，类名不应该是短语。

而方法名应该是动词或者动词短语，如postPayment,deletePage。

 

4.一种概念统一用一种命名规则。

 

对于每个抽象概念选一个词，并且一以贯之。列入，使用get,load,query,find来给不同的DAO定义同样的方法。你怎么记得住那个类中哪个方法。你只能去看看详细看看方法原型，返回值是什么，注释是什么，然后才知道应该调用哪个方法。

 

方法

1.避免写过于复杂的函数。service的代码大部分都非常短小，但是我还是找到一个,下面这段截取自DefaultFormService的代码：

 

  public void init() throws ServiceInitializationException {

        initFormKeys();

 

        ResourceLoaderService resourceLoader = (ResourceLoaderService) getService(ResourceLoaderService.SERVICE_NAME);

 

        formConfig = new FormConfig(this);

 

        // 防止重复装入同一文件

        Set loadedDescriptors = new HashSet();

        StringBuffer rundataKey = new StringBuffer("form" + getInstanceName());

 

        for (Iterator i = getConfiguration().getList(FORM_DESCRIPTORS).iterator(); i.hasNext();) {

            String descriptor = (String) i.next();

            URL descriptorURL;

 

            try {

                descriptorURL = resourceLoader.getResourceAsURL(descriptor);

            } catch (ResourceNotFoundException e) {

                throw new ServiceInitializationException("Invalid URI broker descriptor: " + descriptor);

            }

 

            rundataKey.append(descriptorURL);

 

            if (!loadedDescriptors.contains(descriptorURL)) {

                loadDescriptor(descriptorURL);

                loadedDescriptors.add(descriptorURL);

            }

        }

 

        this.rundataKey = rundataKey.toString();

 

        // 处理group的继承关系

        processGroups();

 

        super.init();

}

也许你会花3分钟时间开懂这段代码，或者在一分半钟已经没有耐心看懂这段代码。这里面有太多的细节一下子展现在我们面前。有太多的不同层级的抽象。奇怪的字符串和函数调用。不过只要简单的方法抽离和重命名，就能让代码清晰很多，下面这段代码，好理解了吗？

重构之后：

public void init() throws ServiceInitializationException {

       initFormKeys();

       this.formConfig = new FormConfig(this);

       this.rundataKey = getRundataKey();

       // 处理group的继承关系

       processGroups();

       super.init();

    }

   

    private String getRundataKey(){

          ResourceLoaderService resourceLoader = (ResourceLoaderService) getService(ResourceLoaderService.SERVICE_NAME);

 

            // 防止重复装入同一文件

            Set loadedDescriptors = new HashSet();

            StringBuffer rundataKey = new StringBuffer("form" + getInstanceName());

 

           for (Iterator i = getConfiguration().getList(FORM_DESCRIPTORS).iterator(); i.hasNext();) {

                String descriptor = (String) i.next();

                URL descriptorURL;

 

                try {

                    descriptorURL = resourceLoader.getResourceAsURL(descriptor);

                } catch (ResourceNotFoundException e) {

                    throw new ServiceInitializationException("Invalid URI broker descriptor: " + descriptor);

                }

 

                rundataKey.append(descriptorURL);

 

                if (!loadedDescriptors.contains(descriptorURL)) {

                    loadDescriptor(descriptorURL);

                    loadedDescriptors.add(descriptorURL);

                }

            }

    }

    定义方法最基本的两条定律：第一规则短小，第二规则还是短小。代码应该短到多少合适？最多不能超过一个屏。最好能三行四行搞定。

 

2.函数内的代码应该保持同一抽象层次。

什么是抽象层次？原生的java API应该是最低抽象层次，比如

StringBuffer sb = StringBuffer(“form”);　

然后我们框架在上面封装属于中间抽象层次,比如:

  ResourceLoaderService resourceLoader = (ResourceLoaderService) getService(ResourceLoaderService.SERVICE_NAME);

最上面抽象层次是领域里面的业务方法。比如

initFormKeys();

之前的代码之所以复杂是因为不同抽象层次的代码混合在一起，导致在阅读代码的时候会有思维跳跃。代码层次越低需要了解的细节越多。我们读书看报都是先看看目录，提纲，最后再看感兴趣的章节，而不会一股脑的全出来所有的内容？代码也是如此。

3. 只做一件事情

         最前面的代码显然做了不只一件事情。函数应该只做一件事情，做好这一件事情。关键是那件事情是什么？代码只做了一件事情,对吧？其实也很容易看成五件事:

1.       初始化initFormKeys。

2.       初始化FormConfig。

3.       初始化getRundataKey。

4.       处理group的继承关系。

5.       初始化父类。

如果函数做的那件事情其实应该是函数命名的那件事，比如postComplaint（）应该做的事情就是发起投诉，发起投诉可能有很多步骤，第一步要检查参数是否有效。第二步要通知诚保，第三部要保存到数据库。如果函数只是做了该函数名下同一抽象层上的步骤，则函数还是只做了一件事情。

 

4.函数参数

1.标识flag参数。

标识参数抽离不堪，向函数中传入一个字符串判断等A做什么行为，等于B做什么行为？不如定义两个函数: doForA(),doForB();

 

2.如果函数有三个，或者三个以上的参数，就说明其中一些参数应该封装为类了。以前我对于这种做法非常粗暴，把所有参数都封装成一个类，这是非常不可取的。需要思考一下，把合适的参数封装到类里面。

有时候会纠结于函数的参数无法封装。比如投诉中方法A需要投诉方ID，被投诉方ID,交易单号，交易类型，投诉类型，而有的地方取不需要投诉类型，且投诉类型和交易信息不应该封装在一个VO里面。

 

3.无副作用

 

4.分割操作和询问

         函数要么做什么事情，要么回答什么事情，但二者不可兼得。看看这个例子：

public boolean setXXX(String attribute,String value);

应函数设置某个属性，如果成功就返回true。如果不存在这个属性就返回false,这样导致如下语句:

if(set(“username”,”unclebob”))..

 

好的方式是应该把操作和询问分开。

If(attributeExist(“username”)){

    setAttribute(“username”,”unclebob”);

}

 

6.       如何做到

Robert说他也无法做到一开始就按照这些规则写函数，一开始也是冗长而复杂，过长的参数列表，名称随意取的，也会有重复代码。但是他会配上一套单元测试，覆盖到每行丑陋的代码，最后打磨这些代码，分解函数，同时保持单元测试通过。

 

注释

1.       不要为了注释而注释。

2.       注释不能美化糟糕的代码。

3.       好的注释：

a)         法律信息

b)         提供信息

c)         对设计意图的解释

d)         警示

e)         TODO 注释

4.       坏的注释

a)         多余的注释

b)         注释掉的代码

c)         归属和署名(这个属于SVN源代码管理工具轻易提供的功能)

 

格式

 

1.       变量的定义和变量的使用不要隔的太远。

2.       相关函数放在一起，若某个函数调用了另外一个，就应该把他们放在一起。而且调用者应该尽可能的放在被调用者的上面。这样程序就有了一个自然的顺序。若坚定地遵守这条约定，读者就能够确信函数声明再起调用后很快出现。

 

数据结构

 

异常处理

 

单元测试