[Refactoring] 긴 함수

긴 함수

• 짧은 함수 VS 긴 함수
  • 함수가 길수록 이해하기 어려워진다. VS 짧은 함수는 더 많은 문맥전환을 필요로 한다.
  • 과거에는 작은 함수를 사용하는 경우에 더 많은 서브루틴 호출로 인한 오버헤드가 있었다.
  • 작은 함수에 좋은 이름을 사용했다면 해당 함수의 코드를 보지 않고도 이해할 수 있다.
  • 어떤 코드에 주석을 남기고 싶다면, 주석 대신 함수를 만들고 함수의 이름으로 의도를 표현해보자.
• 이에 해당하는 리팩토링 기술은 7종류가 있다.
  • 문제의 99%는 함수 추출하기(Extract Funtion)로 해결할 수 있다.
  • 함수로 분리하면서 해당 함수로 전달해야 할 매개변수가 많아진다면 다음과 같은 리팩토링을 고려해볼 수 있다.
    • 임시 변수를 질의 함수로 바꾸기 (Replace Temp with Query)
    • 매개변수 객체 만들기 (Introduce Parameter Object)
    • 객체 통째로 넘기기 (Preserve Whole Object)
  • 조건문 분해하기 (Decompose Conditional)를 사용해 조건문을 분리할 수 있다.
  • 같은 조건으로 여러개의 Switch 문이 있다면, 조건문을 다형성으로 바꾸기 (Replace Conditional with Polymorphism)을 사용할 수 있다.
  • 반복문 안에서 여러 작업을 하고 있어서 하나의 메소드로 추출하기 어렵다면, 반복문 쪼개기 (Split Loop)를 적용할 수 있다.

임시 변수를 질의 함수로 바꾸기 (Replace Temp with Query)

---

• 변수를 사용하면 반복해서 동일한 식을 계산하는 것을 피할 수 있고, 이름을 사용해 의미를 표현할 수도 있다.
• 긴 함수를 리팩토링할 때, 그러한 임시 변수를 함수로 추출하여 분리한다면 빼낸 함수로 전달해야 할 매개변수를 줄일 수 있다.

매개변수 객체 만들기 (Introduce Parameter Object)

---

• 같은 매개변수들이 여러 메소드에 걸쳐 나타난다면 그 매개변수들을 묶은 자료 구조를 만들 수 있다.
• 그렇게 만든 자료구조는 ?
  • 해당 데이터간의 관계를 보다 명시적으로 나타낼 수 있다.
  • 함수에 전달할 매개변수 개수를 줄일 수 있다.
  • 도메인을 이해하는데 중요한 역할을 하는 클래스로 발전할 수도 있다.

객체 통째로 넘기기 (Preserve Whole Object)

---

• 어떤 한 레코드에서 구할 수 있는 여러 값들을 함수에 전달하는 경우, 해당 매개변수를 레코드 하나로 교체할 수 있다.
• 매개변수 목록을 줄일 수 있다.
• 이 기술을 적용하기 전에 의존성을 고려해야 한다.
• 어쩌면 해당 메소드의 위치가 적절하지 않을 수도 있다.
  • 기능 편애 Feature Envy 냄새에 해당한다.

조건문 분해하기 (Decompose Conditional)

---

• 여러 조건에 따라 달라지는 코드를 작성하다보면 종종 긴 함수가 만들어진다.
• 조건과 액션 모두 의도를 표현해야한다.
• 기술적으로는 함수 추출하기와 동일한 리팩토링이지만 의도만 다를 뿐이다.

함수를 명령으로 바꾸기 (Replace Function with Command)

---

• 함수를 독립적인 객체인, Command로 만들어 사용할 수 있다.
• 커맨드 패턴을 적용하면 다음과 같은 장점을 취할 수 있다.
  • 부가적인 기능으로 undo 기능을 만들 수도 있다.
  • 더 복잡한 기능을 구현하는데 필요한 여러 메소드를 추가할 수 있다.
  • 상속이나 템플릿을 활용할 수도 있다.
  • 복잡한 메소드를 여러 메소드나 필드를 활용해 쪼갤 수도 있다.
  • 대부분의 경우에 커맨드 보다는 함수를 사용하지만, 커맨드 말고 다른 방법이 없는 경우에만 사용한다.

반복문 쪼개기 (Split Loop)

---

• 하나의 반복문에서 여러 다른 작업을 하는 코드를 쉽게 찾아볼 수 있다.
• 해당 반복문을 수정할 때 여러 작업을 모두 고려하며 코딩을 해야한다.
• 반복문을 여러개로 쪼개면 보다 쉽게 이해하고 수정할 수 있다.
• 성능 문제를 야기할 수 있지만, 리팩토링은 성능 최적화와 별개의 작업이다. 리팩토링을 마친 이후에 성능 최적화 시도할 수 있다.

조건문을 다형성으로 바꾸기 (Replace Conditional with Polymorphism)

---

• 여러 타입에 따라 각기 다른 로직으로 처리해야 하는 경우에 다형성을 적용해서 조건문을 보다 명확하게 분리할 수 있다.
• 반복되는 switch문을 각기 다른 클래스를 만들어 제거할 수 있다.
• 공통으로 사용되는 로직은 상위클래스에 두고 달라지는 부분만 하위클래스에 둠으로써, 달리지는 부분만 강조할 수 있다.
• 모든 조건문을 다형성으로 바꿔야 하는 것은 아니다.

Reference

---

백기선. 코딩으로 학습하는 리팩토링. 인프런. https://www.inflearn.com/course/%EB%A6%AC%ED%8C%A9%ED%86%A0%EB%A7%81/dashboard