代码整洁之道

最近维护一个古老的不能再古老的项目，当楼主看到前辈写的300多行的业务逻辑判断拼接sql语句的代码的时候，内心是崩溃的，更为崩溃的是现在产品告诉你，这里的需求变更了，需要你来维护，
当楼主断然拒绝说这种代码除非重新整理整个需求进行完全重构的时候，写这些代码的老前辈说我来吧。。。多谢老前辈的不杀之恩。

最近项目进度不紧张，楼主一直在进行spring源码的学习和对公司代码进行优化，不得不说，代码的重构和整洁性对程序员来说太重要了，一家公司至少应该保证上一个程序员遗留下来的代码能够
让后面接手的人看懂，但是现实是很多公司和团队难以做到。

今天就代码的重构写一些最近的总结。

 

1：能公用的代码一定要抽出公共的方法，防止大量重复代码的出现

       大量重复的代码导致整个项目臃肿，难以维护，后续需求变更时候需要维护的代码部分也就集中在公共方法内，进行一处修改即可，否则大量重复代码也很容易使后来接手的人难以维护和对
       直接喷编写这段代码的人，作为程序员也应该有一颗代码洁癖的心。

/* ---------------------这是错误的示范---------------------- */
class DiedCode {

    public void bad1(){
        bean.set(1)/* 重复代码 */
        System.out.println(bean.get(1));
    }
    
    public void bad2(){
        bean.set(1)/* 重复代码 */
        System.out.println(bean.get(1));
    }
    
}

/* ---------------------这是正确的示范---------------------- */
class LiveCode {

    public void good1(){
        commonCode();
    }
    
    public void good2(){
        commonCode();
    }
    
    public void good3(){
        bean.set(1)/* 提取重复代码 */
        System.out.println(bean.get(1));
    }
    
}

 

2：严格控制方法体的行数，最好单个方法内不要超过60行
大家可以设身处地的想一下，看到一个完全陌生的代码，这个代码块一个方法内有好几百行代码，你的内心是不是几乎崩溃的，这个方法究竟都做了什么，什么业务需要这么多的代码，
是根据业务拆分的不彻底，还是代码写的太冗长？一个好的代码应该一个方法体内只实现一个功能，保证单一职责性，以免日后需求变更的过程中，需要修改大量的代码。


/* ---------------------这是错误的示范---------------------- */
class DiedCode {

    public void bad(){
    xxx
    xxx
    xxx
    xxx
    }  
}

/* ---------------------这是正确的示范---------------------- */
class LiveCode {
    public void someMethod(){
        function1();
        function2();
        function3();
    }

    private void function1(){
        //function[1]
    }
    
    private void function2(){
        //function[2]
    }

    private void function3(){
        //function[3]
    }
}


3：尽量减少不必要的传参，能够封装成对象的通过传递对象的方式进行参数定义
一个方法体内过多的参数容易引起调用者使用的歧义，在代码里很难做到注释的完全展示，好的方法体的代码应该能够让调用者很清晰的了解传入和返回的参数类型和值域内容，
当一个方法内定义了大量零散的参数的时候，容易让新接手代码的调用者摸不到头脑。
 
/* ---------------------这是错误的示范---------------------- */
class DiedCode {
    public void someMethod(int i,int j,int k,int l,int m,int n){
        //code
    }
}

/* ---------------------这是正确的示范---------------------- */
class LiveCode {
    public void someMethod(Bean bean){
        //code
    }
}

 class bean{
    
    private int a;
    private int b;
    private int c;
    private int d;
    private int e;
    private int f;
　　//getter&&setter
    
}

 

4.尽量减少判断条件，不允许超过两层的判断嵌套，多条件的判断使用switch替代else if



 

小实例

           
/* ---------------------这是错误的示范---------------------- */
class DiedCode {

    public void someMethod(Object A,Object B){
        if (A != null) {
            if (B != null) {
                xxx
            }else if(C != null){
                xxx
            }else{
            xxx
        }
        }else{
        xxx
        }
    }
    
}

/* ---------------------这是正确的示范---------------------- */

class LiveCode {

    public void someMethod(Object A,Object B){
        if(A == null){
            xxx
        }
        switch(B){
    case:1
      xxx;
      break;
     default:
      xxx
      break;
    }
    }
    
}

 

5：多个类中引用的变量尽量定义为静态变量，共同引用

这个没什么可说的，比如一个默认的user_id定义为0，一个项目可以共同引用，当需求变更需要修改变量内容的时候只需要修改一处即可，不允许每个类中自己定义这些公共的变量


就先写到这里，代码重构的知识远不止这些，仅仅针对最近遇到的问题和楼主使用的方案进行了简单的总结，楼主也还需要在日后的工作中多多学习。

结束语

    代码重构是一个系统工程，需要开发人员大量的耐心和极好的脾气，因为在大多数公司都处于代码能用即可，尽量减少接手原来代码的变更，减少问题出现的概率，
    但是楼主最近遇到的代码实在让人难以忍受，作为一个程序员，至少应该做到让后来的人看到自己的代码能够看懂，并且别再心里骂自己代码写的垃圾。。。