깨끗한 코드를 작성하는 방법.

그림


수년 동안 일하면서 코드가 깨끗하고 깔끔하다는 것이 정말 중요하다는 것을 점점 더 느끼고 있습니다! 특히 팀 개발에서 우아하고 깔끔한 코드를 작성하면 동료가 더 기꺼이 협력할 수 있습니다.

아래에서는 네이밍, 클래스, 함수, 테스트 4개의 챕터를 통해 코드를 깔끔하게 만들어 보겠습니다.

1. 왜 코드를 깨끗하게 유지해야 합니까?

정돈되지 않은 코드가 시간이 지남에 따라 증가하면 생산성이 감소합니다.

  • 코드 확장이 쉽지 않거나 확장으로 인해 다른 문제가 발생하기 쉽습니다.
  • 프로그램 충돌
  • 초과로 일하다
  • 회사의 비용이 증가하고(인력 추가) 회사가 파산할 수도 있습니다.

그림

1.1 따라서 처음부터 깔끔하게 유지하십시오.

그래서 처음부터 깨끗한 코드를 작성하고 어수선한 코드가 있으면 제 시간에 수정해야 합니다. 나중에 변경할 생각이 절대 없기 때문입니다!

later equal never
复制代码

이것이 이유인지, 나중에 이야기하고 나중에 변경할 것이 얼마나 많은지 모두 남겨 둡니다.

해야 할 일이 있다면 일찍 하라!

1.2 깨끗한 코드를 작성하는 방법?

이제 문제는 어떤 종류의 코드가 클린 코드인가 하는 것입니다.

  • 가독성이 높아야 합니다: 코드는 산문처럼 우아하고 읽기 쉬워야 합니다. 이해를 위해 코드를 참조하세요.
  • 중복 코드 거부
  • 디자인 패턴 원칙 충족
    • 단일 책임
    • 개폐 원리
    • Liskov 대체 원리
    • 종속성 역전 원칙
    • 인터페이스 분리 원리
    • 데메테르의 법칙
    • 합성 다중화 규칙

2. 네이밍

좋은 이름 지정은 코드의 가독성을 높이고, 사람들이 코드를 이해하게 만들고, 이해 비용을 줄이고, 효율성을 높이고, 초과 근무를 줄일 수 있습니다.

2.1 나쁜 이름

  1. 의미 없는 네이밍
public interface Animal {
    void abc();
}
复制代码

이제 우리는 사람들을 혼란스럽게 만드는 abc() 메서드가 있는 동물 인터페이스를 가지고 있으며, 이 메서드를 호출하는 사람은 그의 이름이 무의미하기 때문에 이 메서드가 무엇을 하는지 전혀 모릅니다.

의미 있는 명칭:

public interface Animal {
    void cry();
}
复制代码

메서드 이름을 cry(외침, 외침)라고 지정하면 호출자는 이 메서드의 기능이 무엇인지 알 수 있습니다.

그래서 네이밍은 의미가 있어야 하고 사람들이 코드를 알 수 있어야 합니다.

  1. 네이밍의 불일치는 분명히 같은 동작이지만 다른 이름이 있다는 사실에 반영되어 일관성이없고 혼란 스럽습니다.
public interface StudentRepository extends JpaRepository<AlertAllString> {
    Student findOneById(
            @Param("id") String id
    );

    List<StudentqueryAllStudent(
    );

}
复制代码

위의 두 가지 방법은 xxx를 조회하는 방법인데 이름을 잠시 조회하고 잠시 찾는다.이 상황을 표준화하고 일관성을 유지해야 한다.수정 후

public interface StudentRepository extends JpaRepository<AlertAllString> {
    Student findOneById(
            @Param("id") String id
    );

    List<StudentfindAll(
    );

}
复制代码
  1. 命名冗余 体现在命名有很多没必要的成分在里面, 并且这些"废话"并不能帮助区分它们的区别, 例如在变量命名中添加了 Variable 这个词, 在表名中添加了 Table 这个词.所以命名中不要出现冗余的单词 , 并且提前约定好命名的规范.
// 获取单个对象的方法用get做前缀
getXxx();
//获取多个对象用list做前缀
listXxxx();
复制代码

3.类

整洁的类应满足一下内容:

  • 单一职责
  • 开闭原则
  • 高内聚性

3.1单一职责

类应该短小,类或模块应有且只有一条加以修改的理由 , 如果一个类过于庞大的话,那么说明它承担的职责过多了.

优点:

  • 降低类的复杂度
  • 提高类的可读性
  • 提高系统的可维护性
  • 降低变更引起的风险

如何判定类是否足够短小?

通过计算类的职责来判断是否够短小,类的名称描述其全责, 如果无法为某个类命以准确的名称, 这个类大概就太长了, 类名越含糊,可能拥有越多的职责.

职责过多的例子,可以看到以下类有两个职责:

public abstract class Sql {
    // 操作SQL的职责
    public abstract void insert();


    // 统计SQL操作的职责
    public abstract void countInsert();

}
复制代码

将统计的职责抽取到另一个类

public abstract class CountSql {

    public abstract void countInsert();

}
复制代码

3.2 开闭原则

开闭原则: 面向修改关闭, 面向扩展开放.

面向修改关闭意味着增加新的逻辑不会修改原有的代码,降低了出错的可能性.

面向扩展开放则是提高了代码的可扩展性,可很容易的增加新的代码逻辑.

不满足开闭原则的例子:

public abstract class Sql {
    public abstract void insert();
    public abstract void update();
    public abstract void delete();
}
复制代码

如果我们现在要新增查询的操作,就需要修改Sql这个类,没有做到面向修改关闭

重构后:

public abstract class Sql {
    public abstract void generate();


}

public class CreateSql extends Sql {

    @java.lang.Override
    public void generate() {
        // 省略实现
    }
}


public class UpdateSql extends Sql {

    @Override
    public void generate() {
        // 省略实现
    }
}
复制代码

当我们要增加删除方法时可以很容易的扩展.

使用大量的短小的类看似比使用少量庞大的类增加了工作量(增加了更多的类),但是真的是这样吗? 这里有一个很好的类比:

你是想把工具归置到有许多抽屉、每个抽屉中装有定义和标记良好的组件的工具箱呢, 还是想要少数几个能随便把所有东西扔进去的抽屉?

最终的结论:

系统应该由许多短小的类而不是少量巨大的类组成,每个小类封装一个权责,只有一个修改的原因,并与少数其他类一起协同达成期望的系统行为.

3.3 内聚

方法操作的变量越多,就越粘聚到类上. 如果一个类中的每个变量都被每个方法所使用, 则该类具有最大的内聚性.  我们应该将类的内聚性保持在较高的位置. 内聚性高意味着方法和变量互相依赖, 互相结合成一个逻辑整体.

为什么要保持高内聚? 保持内聚性就会得到许多短小的类,就越满足单一职责.

内聚性低怎么办? 如果类的内聚性就不够高,就将原有的类拆分为新的类和方法.

4.函数

要想让函数变得整洁,应保证:

  • 只做一件事
  • 好的命名
  • 整洁的参数
  • 注意返回内容

4.1 只做一件事

what? 函数的第一规则是短小 第二规则是更短小 短小到只做一件事情. (没错和类的原则很像)

why? 函数越短小,越能满足单一职责.

how? 以下是重构前的代码, 这个方法有三个职责,并且该方法很长达到了80+50+5 = 135行

public class PicService {

    public String upload(){
        // 校验图片的方法 伪代码80行

        // 压缩图片的方法 伪代码50行

        // 返回成功或失败标识 0,1 伪代码5行
        return "0";
    }
}
复制代码

原有的upload方法做了很多的事情, 重构后只做了一件事情: 把大一些的概念(换言之,函数的名称)拆分为另一抽象层上的一系列步骤:

 public String upload(){
        // 校验图片的方法
        check();
        // 压缩图片的方法
        compress();
        // 返回成功或失败标识 0,1
        return "0";
    }
复制代码

而里面的每个方法,也都有着自己各自的职责(校验图片 、压缩图片 、返回结果).

4.2 函数命名

1. 函数名应见名知意

函数要有描述性的名称,不要害怕长名称.

不好的命名方式:

public String addCharacter(String originString, char ch);
复制代码

这个函数,一咋看,还不错,从函数字面意思看是给某个字符串添加一个字符。但是到底是在原有字符串首部添加,还是在原有字符串末尾追加呢?亦或是在某个固定位置插入呢?从函数名字完全看不出来这个函数的真正意图,只能继续往下读这个函数的具体实现才知道。

而下面这几个名字就比上面要好得多:

// 追加到末尾
public String appendCharacter(String originString, char ch);   

// 插入指定位置
public String insertCharacter(String originString, char ch, int insertPosition);
复制代码

2. 函数应该无副作用

函数应该无副作用, 意思就是函数应该只做一件事,但是做这件事的时候做了另一件有副作用的事情.

例如: 校验密码时会初始化 session,导致会话丢失。如果无法移除这种副作用,应该在方法名中展示出来,避免用户误用 checkPasswordasswordAndInitializeSession, 从命名上就要体现副作用.

4.3 参数

1. 参数越少越好

参数越少,越容易理解,参数超过三个可以将参数进行封装,要按参数的语义进行封装,不一定封装成一个大而全的参数,可以封装为多个,原则是按语义补充; 示例:

public List<Student> findStudent(int age, String name, String country, int gender);

//封装参数
public List<Student> findStudent(Student student);
复制代码

2. 不要使用标识参数

标识参数是参数为 Boolean 类型, 用户传递 true or false . 不要使用标识参数因为这意味着你的函数违背了单一职责(true false 两套逻辑). 正确的做法是拆分为两个方法:

//标识参数方法
render(Boolean isSuite);

//重构为两个方法
reanderForSuite();
renderForSingleTest();
复制代码

3. 不要使用输出参数

什么是输出参数?

将变量作为参数传入方法,并且将变量输出, 这就是输出参数

public void findStudent(){
Student student = new Student();
doSomething(student);
return student;
}

int doSomething(Student student){
// 省略一些student逻辑
return student;
}
复制代码

为什么不应该有输出参数?

因为增加了理解成本在里面,我们需要查看 doSomething到底对 student 做了什么. student 是输入还是输出参数? 都不明确.

重构:

// 将doSomething()方法内聚到student对象本身
student.doSomething();
复制代码

4.4 返回值

1. 分离指令与讯问

示例代码:

Pulic Boolean addElement(Element element)
复制代码

指令为增加某个元素,询问是否成功,

这样做的坏处是职责不单一,所以应该拆分为两个方法

public void addElement(Element element);
public Boolean isAdd(Element element);
复制代码

2. 使用异常替代返回错误码

直接抛出异常,而不是返回错误码进行判断, 可以使代码更简洁. 因为使用错误码有可能会进行多层嵌套片段 代码示例:

// 使用错误码导致多层嵌套...
public class DeviceController{

 public void sendShutDown(){
  DeviceHandle handle=getHandle(DEV1);
   //Check the state of the device 
  if (handle != DeviceHandle.INVALID){
   // Save the device status to the record field 
   retrieveDeviceRecord(handle);
   // If nat suspended,shut down
   if (record.getStatus()!=DEVICE_SUSPENDED){
     pauseDevice(handle);
     clearDeviceWorkQueue(handle);
     closeDevice(handle);
   }else{
    logger.log("Device suspended. Unable to shut down"); 
   }
  }else{
   logger.log("Invalid handle for: " +DEV1.tostring()); 
 }
复制代码

重构后:

//  将代码拆分为一小段一小段, 降低复杂度,更加清晰
public class DeviceController{

 public void sendShutDowm(){ 
  try{
   tryToShutDown();
  } catch (DeviceShutDownError e){ 
   logger.log(e);
  }

 private void tryToShutDown() throws DeviceShutDownError{
   DeviceHandle handle =getHandle(DEV1);
   retrieveDeviceRecord(handle);
   pauseDevice(handle);
   clearDeviceWorkQueue(handle);
   closeDevice(handle);
 }

 private DeviceHandle getHandle(DeviceID id){
              // 省略业务逻辑
  throw new DeviceShutDownError("Invalid handle for:"+id.tostring()); 
 }
}
复制代码

4.5 怎样写出这样的函数?

没人能一开始就写出完美的代码, 先写出满足功能的代码,之后紧接着进行重构

为什么是紧接着? 因为 later equal never!

4.6 代码质量扫描工具

使用 SonarLint 可以帮助我们发现代码的问题,并且还提供了相应的解决方案. 对于每一个问题,SonarLint 都给出了示例,还有相应的解决方案,教我们怎么修改,极大的方便了我们的开发

比如,对于日期类型尽量用 LocalDate、LocalTime、LocalDateTime,还有重复代码、潜在的空指针异常、循环嵌套等等问题。

有了代码规范与质量检测工具以后,很多东西就可以量化了,比如 bug 率、代码重复率等.

5.测试

测试很重要,可以帮助我们验证写的代码是否没问题,同样的测试代码也应该保持整洁.

5.1 TDD

TDD는 애자일 개발의 핵심 사례이자 기술이자 설계 방법론인 테스트 주도 개발입니다.

  • 장점: 모든 개발 노드에서 사용할 수 있고 몇 가지 버그가 포함되어 있으며 특정 기능이 있고 출시할 수 있는 제품을 만들 수 있습니다.
  • 단점: 코드의 양이 증가합니다. 테스트 코드는 시스템 코드의 두 배 이상이지만 동시에 디버깅 및 오류 찾기에 대한 시간을 절약합니다.

어떻게?

  1. 코드를 개발하기 전에 테스트 작성
  2. 통과하지 못하고 컴파일되지 않고 통과하지 않는 단위 테스트만 작성할 수 있습니다.
  3. 개발 코드는 테스트를 초과할 수 없습니다.

2에 대한 설명: 단위 테스트는 프로덕션 코드와 동시에 수행되며 컴파일할 수 없는 단위 테스트가 작성되면 프로덕션 코드가 작성되기 시작합니다. 이 주기가 반복되며 단위 테스트는 모든 프로덕션 코드를 포함할 수 있습니다.

5.2 첫 번째 원칙

FIRST 원칙은 단위 테스트 작성을 안내하는 원칙입니다.

  • 빠른 빠른 단위 테스트 실행이 빠르게 완료되어야 합니다.
  • 독립 독립 단위 테스트는 서로 독립적입니다.
  • 반복 가능 반복 가능한 단일 테스트는 환경에 의존하지 않고 어디서나 실행할 수 있습니다.
  • 자체 유효성 검사 프로그램은 수동 유효성 검사 없이 출력 부울을 통해 자체 유효성 검사를 수행할 수 있습니다(로그 출력 참조, 두 파일 비교 등).
  • 시기 적절한 단위 테스트는 프로덕션 코드 전에 작성됩니다.

단위 테스트는 코드 테스트의 기본 테스트입니다.FIRST는 좋은 단위 테스트를 작성하기 위한 중요한 원칙입니다.단위 테스트는 빠르고 독립적이며 반복 가능하고 자체 검사가 가능하며 시기 적절하고 완전해야 합니다.

5.3 테스트 코드 패턴

코드 개발 및 테스트는 given-when-then 패턴을 사용할 수 있습니다.

  • 주어진 시뮬레이션 데이터를 제조합니다.
  • 테스트 코드를 실행할 때
  • 테스트 결과 확인

코드 예제

/**
  * If an item is loaded from the repository, the name of that item should 
  * be transformed into uppercase.
  */
@Test
public void shouldReturnItemNameInUpperCase() {
 
    // Given
    Item mockedItem = new Item("it1""Item 1""This is item 1"2000, true);
    when(itemRepository.findById("it1")).thenReturn(mockedItem);
 
    // When
    String result = itemService.getItemNameUpperCase("it1");
 
    // Then
    verify(itemRepository, times(1)).findById("it1");
    assertThat(result, is("ITEM 1"));
}
复制代码

테스트 코드의 가독성을 높이려면 give-when-then 패턴을 사용하십시오.

5.4 단일 테스트 자동 생성

단일 테스트를 자동으로 생성하는 IDEA용 플러그인 2개 도입

  • Squaretest 플러그인(유료)
  • TestMe 플러그인(무료)

6. 결론

깨끗한 코드를 작성하면  코드의 가독성을 높이고 코드의 확장성을 높일 수 있습니다.

출처: www.cnblogs.com/liuboren/p/…

Guess you like

Origin juejin.im/post/7213406013638295607