Clean Method

≫ 유지보수성 높은 Clean Method의 조건

   1. Method를 호출하는 사람이 사용하기 용이해야 한다.
   2. Method를 유지보수 하는 사람이 이해하고, 변경하기 용이해야 한다.
   3. Method를 유지보수 하는 사람이 테스트하기 용이해야 한다.

 

 

▶ Clean Method의 원칙
· 가능한 한 충분히 작아야 한다.
· 한 가지를 해야 한다. 그리고 그 한 가지를 잘 해야 한다.
· 테스트 가능해야 한다.
· 중복이 없어야 한다.

 

 

Method를 만들 때 Method를 호출하는 사람의 인지적 부하를 최소로 만들어 주어야 한다. 즉, Method를 호출할 때마다 내부 코드를 보거나 API 문서를 보지 않게끔 해야한다는 것이다. 인지적 부하를 낮추는 가장 좋은 방법은 Method의 Parameter의 개수를 가능한 한 최소로 유지하는 것이다.

 

그럼 Prameter의 개수는 몇개가 가장 좋을까?

개수에 따른 인지적 부하의 예 

 

Parameter의 개수가 3-4개 이상일 때 고려할 수 있는 방법을 알아보자.

 

1. Method를 분할한다.

  → Method가 너무 많은 역할을 하고 있을 가능성이 있다. 따라서 명확히 한 가지 역할을 하는 2개 이상의 Method로 분할하는 것이 좋다.

 

2. Parameter Object를 사용한다.

  → method를 호출할 때, 실제 인자로 수많은 정보가 필요할 때는 여러 개의 인자를 primitive로 사용하는 것 보다 이러한 데이터를 담고 있는 클래스를 생성하여 Object를 생성하여 넘겨주는게 좋다.

      ex) saveProduct(product) // name, type, price, instructor, description, ...

 

3. 생성자의 경우 Builder Pattern을 활용한다.

  → 객체를 생성할 때 객체 자체가 담고있는 데이터가 많으면 생성자가 복잡해질 수 있다. 이럴경우, Builder Pattern을 활용하게 되면 필요한 것들만 명확하게 세팅하여 build하면 객체를 생성하게 된다.

      ex) Product("cleancode", "course", 10, "Dahye", ...) _ 일반

            Product.builder().name("cleancode").type("course").price(10).build() _ Builder Pattern 활용

 

4. Map을 사용한다.

  → Parameter의 개수가 많을 시 Map 사용의 유혹이 있다. 그러나 Map 사용시 몇 가지 문제점이 존재한다. Map의 Key값이 유동적이기 때문에 추가적인 문서화가 필요하고, Map의 Key의 정보나 개수가 변경되었을 시 알기가 어렵다. 또한 호출하는 사람이 Key 값에 오타를 입력했을 경우 에러가 발생한다.

 

 

앞에서 좋은 method는 작고, 한 가지 일을 해야한다 했다. 그렇다면 먼저 Clean Method는 얼마나 작아야할까?

 

≫ 작고 역할이 명확한 메소드의 장점

   ·  읽고 이해하기 용이하다.

   ·  기존 코드를 수정하기 용이하다.

   ·  단위 테스트하기가 용이하다.

   ·  재사용성이 높다.

 

Rules of Thumb
 · 10~100 라인 사이가 적절하다. 그러나 숫자에 집착할 필요는 없다.
 · 1개의 Method는 스크롤링을 하지 않고 읽을 수 있어야 한다.
 · 단위 테스트 케이스를 작성하는데 어려움이 없어야 한다.
 · Method 동작을 설명하기 위해 내부에 주석을 달아야 하면 Bad Smell이다.
   (주석이 필요한 코드들은 새로운 Method로 추출한다)

 

 

 

Method의 크기에 대해 알아봤으니 이번엔 한 가지의 명확한 역할을 한다는 것은 무엇인지 알아보자.

 

≫ 한 가지의 명확한 일을 하는 Method의 장점

  · 명확한 Naming이 가능하고, 이름만으로 기능을 이해할 수 있다.

  · 복잡도가 낮아질 가능성이 높다.(Cyclomatic Complexity) → 조건문의 복잡한 중첩구조가 적다.

  · Method의 내부 코드를 이해하고 수정하기 용이하다.

  · 단위 테스트하기가 용이하다.

 

 

 

한 가지의 일이란 무엇일까?

 

 

1. 하나의 Method는 동일한 추상화의 수준만 가져야 한다.

 

* 추상화의 수준(Level of Abstraction)이란?

추상화의 수준 예시

Higher Level과 Lower Level 비교

 

회원가입 method를 예시로 한 method 안에 추상화 수준이 동일하게 구성되었는지 보자.

코드의 아래로 내려갈수록 Higher Level 이다.

전체적으로 intermediate Level 이다.

 

또 다른 추상화 수준의 예를 보자.

추상화의 수준을 위반한 케이스

4개의 method 모두 하나의 method는 동일한 추상화의 수준을 가져야 한다는 것을 잘 지킨 케이스

 

 

 

2. Method의 이름이 책임지는 범위의 일만 해야 한다.

 

구성하고자 하는 시스템의 영역을 정하면 그 시스템은 책임지는 일만 해야한다.

 

이름의 책임을 벗어나는 Bad Smell의 예시를 보자.

 

 

---

 

Clean Method를 만들기 위한 가장 중요한 것은 지속적인 개선이다

한 가지를 잘하는 Method를 만드는 것은 어렵다. 

따라서

충분히 작은가, 충분히 테스트 되고 있는가? 끊임없는 질문과 개선이 중요하다. 

처음부터 거대한 Method는 적다. 하지만 잠깐의 유혹들이 점점 거대한 Method를 만들게 되는 것이다. 따라서 설계에 대한 고려 없이 기존 Method에 기능을 추가하는 것은 위험하다.

 

 

---

 

중복 코드

일정 라인 수 이상이 다수 중복되어 존재하는 코드

 

중복 코드의 종류

1. Method 전체 코드 중복

  : 다수의 Method의 구현부가 100% 일치하는 경우 (* Method 이름은 다를 수 있음)

 

2. 연속 된 일련의 코드 중복

  : Method 전체는 아니지만 일부 연속 된 코드가 다수 중복되는 경우 (* 중복 코드의 대다수를 차지하는 유형)

 

3. 일부만 다른 코드 중복

  : 코드가 중복되지만 중간 1-2 라인 정도만 다른 경우 (* Refactoring하기 가장 까다로운 유형)

위, 아래의 코드는 같지만 가운데 몇 라인만 다른 경우

 

 

중복 코드의 문제점

 - 불필요하게 코드 베이스를 크게 만든다. (코드베이스가 크면 유지보수성을 떨어뜨린다)

 - 코드를 수정해야 할 때 중복된 다수의 코드를 모두 수정해야 한다. (일부 누락될 시 에러가 발생할 수 있다)

 - 중복 코드에 잠재적 결함이 있을 시, 결함도 같이 중복 된다.

 

 

중복 코드를 발견하는 법

 - 코드 리뷰를 한다. (But, 수동으로 전체 SW 시스템의 중복을 다 발견하기는 쉽지 않다)

 - 정적 분석을 한다. (CPD, Atomiq 등의 정적 분석 도구를 활용한다)

 - 다양한 Refactoring 전략 및 Design Pattern을 적용한다.

   (Extract Method, Extract Superclass, Template Method Pattern)

 

 

---

 

※ 보이스카우트 법칙

    : 캠프장에 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라 (= 체크아웃 할 때보다 조금이라도 더 깨끗한 코드를 체크인 하라)

     → 아주 작은 개선이라도 지속되면 코드는 나빠지지 않는다.

          (ex. 조금 긴 함수를 분할, 중복 코드를 제거, 복잡한 if문 1개 정리 등)

 

 

보이스카우트 규칙이 제대로 진행되기 위해서는

 

1. Clean Code를 장려하는 문화가 형성되어야 한다.

    → 코드를 개선하려는 노력을 무시해서는 안된다.

 

2. 단위 테스트 코드가 있어야 한다.

    → 수정 후에는 항상 기존 기능에 영향이 없음을 검증해야 한다.

    → 수정 후에는 테스트 코드를 실행하여 문제가 없음을 확인한다.

 

 

※ 비자아적 프로그래밍(Egoless Programming)

  : 엔지니어 개개인의 요소들을 최대한 제거함으로써 전체 SW 품질을 높이는 문화

   ( 각자 만든 코드에 개인의 자아를 투영하지 말아야 함, 프로젝트 초기부터 지속적인 코드리뷰를 하며 공동 책임 철학을 강조)

 

▷ 비자아적 프로그래밍을 위한 가이드_Jeff Atwood
  · 당신이 실수 할 수 있다는 것을 받아 들여라
  · 당신과 당신이 작성한 코드는 다르다.
  · 당신보다 지식이 적은 사람이라도 존중하고 인내를 갖고 대하라.
  · 세상에 고정되어 있는 것은 없다. 변화를 받아들여라.
  · 사람이 아닌 코드를 비판해라. 사람에게는 친절히 대하라.

 

 

★ 따라서, Clean Method를 만들기 위해서는

 · Parameter의 개수는 적게,
 · Clean Name으로 명확하게,
 · 크기는 작게,
 · 역할은 명확하게,
 · 중복 없는 상태로,
 · 테스트 커버리지와 테스트 용이성은 높게.  해야한다.

 

 

---

 

코드프레소 Java 웹 개발 체험단 활동 중 'SW 유지보수성 향상을 위한 Clean Code' 이러닝 강의를 듣고 작성하였습니다 :)
코드프레소 URL: https://www.codepresso.kr/

프리미엄 IT 교육 서비스 - 코드프레소