TIL (2022.01.26)

DAY 6

🔖 오늘 읽은 범위 : 3장, 함수 (~p.54 함수 인수)

😃 책에서 기억하고 싶은 내용을 써보세요.

• 작게 만들어라
  • 함수를 만드는 첫째 규칙은 ‘작게!’다. 함수를 만드는 둘째 규칙은 ‘더 작게!’다. 이 규칙은 근거를 대기 어렵다. (...) 지금까지 경험을 바탕으로 그리고 오랜 시행 착오를 바탕으로 나는 작은 함수가 더 좋다고 확신한다.
  • 함수가 얼마나 짧아야 하느냐고? 일반적으로 목록 3-2보다 짧아야 한다!
  • 블록과 들여쓰기
    • if 문/else 문/while문 등에 들어가는 블록은 한 줄이어야 한다는 의미다. 대게 거기서 함수를 호출한다. (...) 이 말은 중첩 구조가 생길 만큼 함수가 커져서는 안 된다는 뜻이다. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다.
• 한 가지만 해라!
  • 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지 만을 해야 한다.
  • 이 충고에서 문제라면 그 ‘한 가지’가 무엇인지 알기 어렵다는 점이다.
    • 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다. (간단한 TO 문단으로 표현 가능)
    • 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.
  • 함수를 만드는 이유는 큰 개념을 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서 가 아니던가.
• 함수 당 추상화 수준은 하나로!
  • 함수가 확실히 ‘한 가지’ 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.
  • 위에서 아래로 코드 읽기: 내려가기 규칙
    • 코드는 위해서 아래로 이야기처럼 읽혀야 좋다.
    • 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 즉, 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 단계씩 낮아진다. 나는 이것을 내려가기 규칙이라고 부른다.
    • 핵심은 짧으면서도 ‘한 가지’만 하는 함수다. 위에서 아래로 TO 문단을 읽어 내려가듯이 구현하면 추상화 수준을 일관되게 유지하기 쉬워진다.
• Switch문
  • ‘한 가지’ 작업만 하는 switch문도 만들기 어렵다. 본질적으로 switch문은 N가지를 처리한다.
  • 하지만 switch문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법은 있다. 물론 다형성(polymorphism)을 이용한다.
    • 목록 3-5는 switch 문을 추상 팩토리(ABSTRACT FACTORY)에 꽁꽁 숨긴다. 팩토리는 switch문을 사용해 적절한 Employee 파생 클래스의 인스턴스를 생성한다. calculatePay, isPayday, deliverPay 등과 같은 함수는 Employee 인터페이스를 거쳐 호출된다. 그러면 다형성으로 인해 실제 파생 클래스의 함수가 실행된다.
• 서술적인 이름을 사용하라!
  • 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.
  • 서술적인 이름을 사용하면 개발자 머릿속에도 설계가 뚜렷해지므로 코드를 개선하기 쉬워진다.
• 함수 인수
  • 함수에서 이상적인 인수 개수는 0개(무항)다. 다음은 1개(단항)고, 다음은 2개(이항)다. 3개(삼항)는 가능한 피하는 것이 좋다. 4개 이상(다항)은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안 된다.
  • 코드를 읽는 사람에게는 includeSetupPageInto(new PageContent) 보다 includeSetupPage()가 더 이해하기 쉽다. includeSetupPageInto(new PageContent) 는 함수 이름과 인수 사이의 추상화 수준이 다르다. 게다가 코드를 읽는 사람이 현 시점에서 별로 중요하지 않은 사항, 즉 StringBuffer를 알아야 한다.
  • 많이 쓰는 단항 형식
    • 함수에 인수 1개를 넘기는 이유로 가장 흔한 경우는 두 가지이다.
      • 하나는 인수에 질문을 던지는 경우다. (ex. boolean fileExists("MyFile"); )
      • 다른 하나는 인수를 무언가로 변환해 결과를 반환하는 경우다.
        (ex. InputStream fileOpen("MyFile");
    • 다소 드물게 사용하지만 그래도 아주 유용한 단항 함수 형식이 이벤트다. 이벤트 함수는 입력 인수만 있다. 출력 인수는 없다.
    • 지금까지 설명한 경우가 아니라면 단항 함수는 가급적 피한다.
  • 플래그 인수 - 플래그 인수는 추하다
  • 이항 함수
    • 물론 이항 함수가 적절한 경우도 있다. Point p = new Point(0,0) 가 좋은 예다. (...) 하지만 여기서 인수 2개는 한 값을 표현하는 두 요소다. 두 요소에는 자연적인 순서도 있다.
    • 이항 함수가 무조건 나쁘다는 소리는 아니다. (...) 하지만 그만큼 위험이 따른다는 사실을 이해하고 가능하면 단항 함수로 바꾸도록 애써야 한다.
  • 인수 객체
    • 인수 2-3개가 필요하다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어본다.
  • 인수 목록
    • 때로는 인수 개수가 가변적인 함수도 필요하다.
    • String.format("%s worked %.2f hours.", name, hours);
    • 위 예제처럼 가변 인수 전부를 동등하게 취급하면 List 형 인수 하나로 취급할 수 있다.
  • 동사와 키워드
    • 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야 한다.
    • 마지막 예제는 함수 이름에 키워드를 추가하는 형식이다. 즉, 함수 이름에 인수 이름을 넣는다. (...) 그러면 인수 순서를 기억할 필요가 없어진다.

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

• 함수를 잘 만드는 방법을 나름대로 파악하고 있다고 생각했는데, 오늘 책을 읽으면서 새롭게 느껴지는 부분들이 있어 놀랐다. 특히 “추상화 수준”과 “함수 인수”가 그러했다.
• “추상화 수준”에 따라 함수를 분리한다는 점이 아직도 명확하게 이해되지는 않는다. (“추상”적인 개념을 명확하게 이해하는 것이 어쩌면 모순 아닐까,,,) 하지만 함수를 단순히 한 기능만 하는 작은 부품으로 여겼던 과거에서 벗어나, “수준”이라는 높낮이 개념을 적용할 수는 있게 되었다. 비슷한 것들끼리 일종의 그룹핑(grouping)과 레벨링(leveling)을 하면서 코드의 가독성이 높아지는 것을 체감할 수 있었다.
• 함수를 만들 때 “함수 인수”가 중요하게 작용할 것이라고 (안타깝게도) 미처 생각해본 적이 없다. 함수를 만들 때 중요한 건 껍데기가 아니라 내부 로직이라고 생각했다. 하지만 함수의 이름과 형태를 정하는 일은, 함수를 작성하기 전 이 함수의 목표를 정하는 일이라는 점을 배울 수 있었다. 목표를 명확하게 할수록 당연히 결과물이 잘 나올 가능성이 높아진다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• LOGO 언어의 키워드 “TO”가 의미하는 바는 무엇인가?
  • LOGO에서 “TO”는 루비나 파이썬의 “def”와 같다. LOGO에서 모든 함수는 “TO”로 시작한다.
  • “TO”는 영어로 “~하려면” 이라는 의미도 된다.
  • 즉, 특정 기능(함수 이름) ‘한 가지‘만을 수행하기 위한 코드들이 해당 함수에 포함되어야 한다는 것을 의미하는 게 아닐까
• 추상화 수준이란?
  • 내가 이해한 추상화는 큰 개념에서 작은 개념들로 쪼개는 것이다. 추상화가 되었다면, 각 개념의 크기가 곧 추상화의 수준이다. 작은 개념일수록 추상화 수준이 낮고, 이들을 결합하는 큰 개념일수록 추상화의 수준이 높다.
  • 다른 분의 해석을 따오자면 다음과 같다. (https://velog.io/@jiwon709/클린코드-작성법-2)

    추상화 수준이란?
    어느 정도까지 디테일한 부분을 숨겼는가에 대한 정도 이다.
    추상화의 수준이 높다라는 것은 디테일을 많이 숨겼다는 것.
    추상화의 수준이 낮다라는 것은 디테일을 많이 드러났다고 볼 수 있다는 것.

소감 3줄 요약

• 함수는 최대한 작게, 한 가지 일만 하게 작성하라
• 추상화 수준에 따라 함수가 해야할 일을 구분하라
• 함수 인수는 최대한 적게 하여 의미를 더욱 명확하게 하자