<aside> ❓ 책에서 기억하고 싶은 내용을 써보세요.

</aside>

• 어떤 프로그램이든 가장 기본적인 단위는 함수

• 함수를 작게 만들어라!

  • 각 함수는 명백하고 이야기 하나를 표현해야 한다.
  • if문/else문/while문 등에 들어가는 블록은 한 줄 이어야 하며 대개 거기서 함수를 호출한다.
  • 중첩구조가 생길만큼 함수가 커져서는 안된다. 그래야 함수를 읽고 이해하기 쉬워진다.

• 함수는 한 가지만 해야 한다!

  함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

  • 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 ‘한 가지’ 작업만 하는 것.
  • 우리가 함수를 만드는 이유는 큰 개념(함수 이름)을 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서.
  • 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈 (한 가지 작업만 하는 함수는 자연스럽게 섹션으로 나누기 어렵다)

• 함수 당 추상화 수준은 하나로!

  • 함수가 확실히 ‘한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.
  • 내려가기 규칙: 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다.
    • 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다.
  • 핵심은 짧으면서도 ‘한 가지'만 하는 함수
  • 각 함수는 다음 함수를 소개하고 각 함수는 일정한 추상화 수준을 유지

• 서술적인 이름을 사용하라!

  • 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.
  • 함수가 작고 단순할수록 서술적인 이름을 고르기도 쉬워진다.
  • 이름을 붙일 때는 일관성이 있어야 한다. 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다.

• 함수에서 인수는 적을수록 좋다!

  • 인수는 개념을 이해하기 어렵게 만든다.
  • 함수 이름과 인수 사이에 추상화 수준은 동일해야 하며 코드를 읽는 사람이 중요하지 않은 세부사항(인수)을 알 필요는 없다.
  • 테스트 관점에서 보면 인수가 많을수록 갖가지 인수 조합으로 함수를 검증해야 한다.
  • 최선은 입력 인수가 없는 경우인 0개, 차선은 입력 인수가 1개인 경우다.
  • 함수에 인수를 1개 넘길 때는 1)인수에 질문을 던지거나(fileExists(”MyFile”)) 2)인수를 뭔가로 변환해 결과를 반환하는 경우(fileOpen(”MyFile”))
    • 함수 이름을 지을 때는 두 경우를 분명히 구분하고 언제나 일관적인 방식으로 두 형식을 사용한다.
  • 플래그 인수는 추하다. 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이다.
  • 함수가 2개인 이항함수는 단항 함수보다 이해하기 어렵다. 가능하면 단항함수로 바꾸자.
  • 함수의 의도나 인수의 순서와 의도를 제대로 표현하려면 좋은 함수 이름이 필수. 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야 한다. ex) write(name)
  • 함수 이름에 키워드를 추가하는 것도 좋다. 즉, 함수 이름에 인수 이름을 넣는 것. 그러면 인수 순서를 기억할 필요가 없다. ex) assertEquals → assertExpectedEqualsActual(expected, actual)

• 부수 효과를 일으키지 마라!

  • 부수 효과는 많은 경우 시간적인 결합과 순서 종속성을 초래한다.

  • 시간적인 결합이 있는 함수는 특정 상황에서만 호출이 가능하다.

    • 예를 들어 checkPassword 라는 함수 내부에서 세션을 초기화할 경우 이 함수는 세션을 초기화해도 괜찮은 경우에만 호출이 가능하다. 자칫 잘못 호출하면 의도하지 않게 세션 정보가 날아간다. → 시간적 결합이 필요하다면 checkPasswordAndInitializeSession 처럼 함수 이름에 명시하는 게 좋다.(하지만 이렇게 되면 함수가 ‘한 가지'만 한다는 규칙을 위반)

  • 출력 인수는 일반적으로 피해야 한다. 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택한다.

    // Bad
    public void appendFooter(StringBuffer report)
    appendFooter(s)
    // Good
    report.appendFooter()
    

• 명령과 조회를 분리하라!

  • 함수는 뭔가를 수행하거나(객체 상태를 변경) 뭔가에 답하거나(객체 정보를 반환) 둘 중 하나만 해야 하며 둘 다 하면 안된다.

    // Bad
    public boolean set(String attribute, String value);
    if (set("username", "unclebob"))...
    // Good
    if (attributeExists("username")) {
    	setAttribute("username", "unclebob");
    	...
    }
    

• 오류 코드보다 예외를 사용하라!

  • 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반. 자칫하면 if문에서 명령을 표현식으로 사용하기 쉬운 탓.
  • 오류 코드를 반환하면 호출자는 오류 코드를 곧바로 처리해야 한다는 문제에 부딪힌다. 반면 오류 코드 대신 예외를 사용하면 오류 처리 코드를 원래 코드에서 분리 가능.
  • 오류 처리도 한 가지 작업. 함수는 ‘한 가지' 작업만 해야 하므로 오류를 처리하는 함수는 오류만 처리해야 마땅하다.

  // Bad
  if (deletePage(page) == E_OK)
  // Good
  try {
  	deletePage(page);
  }
  catch (Exception e) {
  	loggeError(e);
  }
  

• 반복하지 마라!

  • 중복은 소프트웨어에서 모든 악의 근원.
  • 객체 지향 프로그래밍은 코드를 부모 클래스로 몰아 중복을 없앤다.

⇒ 함수를 짜는 것은 글쓰기와 마찬가지.

처음에는 길고 복잡하다. 들여쓰기 단계도 많고 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중복된다. 하지만 나는 그 서투른 코드를 빠짐없이 테스트하는 단위 테스트 케이스도 만든다. 그런 다음 나는 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메소드를 줄이고 순서를 바꾼다. 때로는 전체 클래스를 쪼개기도 한다. 이 와중에도 코드는 항상 단위 테스트를 통과한다.

⇒ 프로그래밍 기술은 언제나 언어 설계의 기술. 언어라는 수단을 사용하여 시스템이라는 이야기를 풀어가는 데에 목표가 있다.

<aside> 📌 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

</aside>

• 함수를 만들 때 기본적으로 한가지 일만 하도록 작게 만들자. 이 기본 원칙을 잊어버리면 안될 것 같다. 내가 작성하는 코드에서도 함수가 여러가지 일을 하는 경우가 많은 것 같다. 최대한 한 가지 일만 하고 이름을 잘 지어서 가장 외부로 드러나는 함수만 보고도 이해가 되도록 코드를 짜자.
• 추상화 수준에 대해 고민하자. 추상화 수준이 동일해야 한다는 것이 명확하게 와닿지 않지만 점점 세부적인 구현으로 들어가야 하는 것 같다.
• 부수효과를 일으키면 안된다. 이름에서 드러나지 않는 일을 내부에서 하도록 코드를 짜면 안된다.
• 예외를 적절하게 잘 사용할 때 코드가 깔끔해지는 것 같다.