클린코드

클린코드 

클린코드란 가독성이 높은 코드를 말한다. -> 즉 어느 개발자가 봐도 쉽게 이해할수 있도록 만들어야한다는 얘기

 

클린코드를 구현하기위해

• 네이밍이 잘 되어야 함
• 오류가 없어야 함
• 중복이 없어야 함
• 의존성을 최대한 줄여야 함
• 클래스 혹은 메소드가 한가지 일만 처리해야 함
• 클린코드의 가장 중요한 요소 중 하나는 가독성이라고 볼 수 있습니다. 즉, 모든 팀원이 이해(understandability)하기 쉽도록 작성된 코드인 것이죠.

함수 이름을 마음대로 지정한다면 나 혼자만 알수있고 나중에 자신이 작성한 코드를 보고도 이해하지 못할 수 있음

public int AAA(int a, int b){
    return a+b;
}
public int BBB(int a, int b){
    return a-b;
}

함수 이름을 잘선택할 경우 다른사람이 보고 그것을 바로 이해할수있음

public int add(int a, int b){
    return a+b;
}

public int sub(int a, int b){
    return a-b;
}

[ 1. 객체의 생성에도 유의미한 이름을 사용하라 ]

// 두 번째 인자가 무엇인지 파악이 어렵다.
Product product = new Product("사과", 10000);

// 이름을 부여하여 두 번째 인자를 명확하게 파악할 수 있다.
Product product = Product.withPrice("사과", 10000);

[ 2. 함수는 하나의 역할만 해야한다. ]

함수는 지정된 이름 아래에서 한 단계 수준의 추상화 수준을 유지해야 한다. 그것이 하나의 역할 및 기능만을 하는 것이다. 또는 의미 있는 다른 함수로 추출가능한 부분이 없다면 그것 역시 하나의 역할 및 기능만을 수행하고 있는 것이다.

예를 들어 다음과 같은 Switch 문은 정말 흔히 작성하는 코드이지만, 많은 문제를 내포하고 있다. (

public Money calculatePay(Employee e) throws InvalidEmployeeType {
  switch(e.type) {
    case COMMISSIONED:
      return calculateCommisionedPay(e);
    case HOURLY:
      return calculateHourlyPay(e);
    case SALARIED:
      return calculateSalariedPay(e);
    default:
      throw new InvalidEmployeeType(e.type);
  }

}

하지만 위의 코드는 다음과 같은 문제점 목록을 가지고 있다.

1. 함수가 너무 길다. 새로운 직원 타입이 추가되면 더 길어질 것이다.
2. 한 가지 작업만을 수행하지 않는다. 해딩 직원이 어느 타입인지 확인하고 있다.
3. SRP를 위반한다. 새로운 직원 타입이 추가되어도 임금을 계산하는 함수를 변경해야 한다.
4. OCP를 위반한다. 새로운 직원 타입이 추가되면 새로운 임금 계산 로직을 위하 코드를 변경해야 한다.
5. 유사한 함수가 계속 파생될 수 있다. 이러한 직원의 타입에 따른 코드는 다른 곳에 중첩될 수 있다.

리팩토링이란?

1) 가독성, 유지보수성

이미 작성한 소스코드에서 구현된 일련의 행위들을 변경없이, 코드의 가독성과 유지보수성을 높이기 위해 내부구조를 변경하는 것이다.

다시 말해 기능을 유지하되 읽기 좋고 지속적으로 관리하기 편하게 소스코드를 재작성하는 것이다.

혼동이 있을 수 있는데, 리펙토링은 가독성과 유지보수성을 목표로하며 성능을 최적화하는 것는 다른 문제이다.

2) 사람, 협업

소프트웨어 개발을 위해 프로그래밍, 소스코드를 작성할 때 대부분 여러명의 사람과 함께 작업을 하게 된다. 그리고 새로움 사람이 내가 작성하는 프로젝트에 추가로 참여하게 되며, 인수인계가 되거나 불가능한 경우도 있다.

같이 협업을 하는 개체가 바로 사람이 되며 사람이 이해하는  코드를 작성하는 것이 중요하다.

리펙토링을 왜 할까?

• 소프트웨어 설계에서 질적 향상을 위해 리펙토링을 한다. 코드 중복을 제거하고, 수정 용이성 향상
• 소프트웨어 이해도를 향하하기 위해, 가독성 향상을 위해 한다. 이 프로젝트에 다른 사람, 다음사람, 그리고 그 사람이 나일 수 도 있다.

개발자 속담 : 남이 짠 소스 내가 고치고, 내가 짠 소스 내가 고친다.

• 버그를 찾는데 도움이 된다.
• 프로그램 개발 속도가 향상된다. 좋은 설계 기반에선, 개발 속도를 단축 할 가능성이 높아진다.

결론....더러운 나의 소스코드에 악취를 제거하기 위해!!!

리펙토링은 언제 할까?

1) The Rule Of Three : 유사한 내용이 세번 이상 반복할 때, 리펙토링을 고려!

똑같거나 비슷한 내용이 세 번이상 작성되있으며 무조건 하는거이 아니라 상황에 고려하여 리펙토링을 결정하는 것이다.

2) 새로운 기능을 추가할 때

지금 작성된 설계, 소스코드에서 새로운 기능을 추가하기 여러워 보이면, 리펙토링을 해야된다. 이러한 상황인 경우 유지보수성이 떨어지며, 가독성 역시 좋지 않을 수 있다.

3) 코드리뷰를 할 때

협업하는 개발팀과 함께 코드리뷰는 질을 높일 수 있다. 그러나 인원이 너무 많은 경우에는 비효율적이므로 소수인원으로 진행하는 걸 권장한다.

그러나 설계 리뷰에서는 많인 인원이 하여도 효과적인다.(개발 프로세스에서 상위 작업임을 고려해라)

클린코드와 리팩토링의 차이?

리팩토링이 더 큰 의미를 가진 것 같다. 클린 코드는 단순히 가독성을 높이기 위한 작업으로 이루어져 있다면, 리팩토링은 클린 코드를 포함한 유지보수를 위한 코드 개선이 이루어진다.

클린코드와 같은 부분은 설계부터 잘 이루어져 있는 것이 중요하고, 리팩토링은 결과물이 나온 이후 수정이나 추가 작업이 진행될 때 개선해나가는 것이 올바른 방향이다.