Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
[TIL / Clean Code] 3장. 함수
#clean_code
2년 전
414


TIL (Today I Learned)

2022.02.22~23

오늘 읽은 범위

3장. 함수

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

  • 어떤 프로그램이든 가장 기본적인 단위가 함수다.(40p)

  • 작게 만들어라!

    • 함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다.(42p)

    • if문/else문/while문 등에 들어가는 블록은 한 줄이어야 한다는 의미다. 대개 거기서 함수를 호출한다. 그러면 바깥을 감싸는 함수(enclosing function)가 작아질 뿐 아니라, 블록 안에서 호출하는 함수 이름을 적절히 짓는다면, 코드를 이해하기도 쉬워진다.
      이 말은 중첩 구조가 생길만큼 함수가 커져서는 안 된다는 뜻이다. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 당연한 말이지만, 그래야 함수는 읽고 이해하기 쉬워진다.(44p)

  • 한 가지만 해라!

    • 함수는 한 가지를 해야한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.(44p)

    • 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다. 어쨌거나 우리가 함수를 만드는 이유는 큰 개념을(다시말해, 함수 이름을) 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서가 아니던가.(45p)

    • 함수가 '한 가지'만 하는지 판단하는 방법이 하나 더 있다. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.(45p)

    • 한 가지 작업만 하는 함수는 자연스럽게 섹션(declarations, initializations, sieve)으로 나누기 어렵다.(45p)

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

    • 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.(45p)

    • 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. 특정 표현이 근본 개념인지 아니면 세부사항인지 구분하기 어려운 탓이다.(46p)

    • 위에서 아래로 코드 읽기 : 내려가기 규칙

      • 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.(46p)

      • 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다.(46p)

  • Switch문

    • [G23:If/Else 혹은 Switch/Case 문보다 다형성을 사용하라]
      선택 유형 하나에는 switch 문을 한번만 사용한다. 같은 선택을 수행하는 다른 코드에서는 다형성 객체를 생성해 switch문을 대신한다.(386p)

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

    • 좋은 이름이 주는 가치는 아무리 강조해도 지나치지 않다. 워드가 말했던 원칙을 기억하는가? "코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다." 한 가지만 하는 작은 함수에 좋은 이름을 붙인다면 이런 원칙을 달성함에 있어 이미 절반은 성공했다. 함수가 작고 단순할수록 서술적인 이름을 고르기도 쉬워진다.(49p)

    • 이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.(49p)

    • 이름을 정하느라 시간을 들여도 괜찮다.(49p)

    • 이름을 붙일 때는 일관성이 있어야 한다.(50p)

  • 함수 인수

    • 함수에서 이상적인 인수 개수는 0개(무항)다.(50p) 

    • 최선은 입력 인수가 없는 경우이며, 차선은 입력 인수가 1개뿐인 경우다.(51p)

    • 함수 이름을 지을 때는 두 경우를 분명히 구분한다. 또한 언제나 일관적인 방식으로 두 형식을 사용한다.(51p)

    • 플래그 인수는 추하다. 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다. 왜냐고? 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까!(52p)

    • 어떤 코드든 절대로 무시하면 안되니까. 무시한 코드에 오류가 숨어드니까(52p)

    • 인수가 2-3개 필요하다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어본다.(53p)

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

    • 부수 효과는 거짓말이다. 함수에서 한 가지를 하겠다고 약속하고선 남몰래 다른짓도 하니까.(54p)

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

    • 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안 된다.(56p)

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

    • 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다.(57p)

    • [try/catch 블록 뽑아내기]

      • try/catch 블록은 원래 추하다. 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞는다. 그러므로 try/catch 블록을 별도 함수로 뽑아내는 편이 좋다.(58p)

    • [오류 처리도 한 가지 작업이다.]

      • 함수는 '한 가지' 작업만 해야 한다. 오류 처리도 '한 가지' 작업에 속한다.(59p)

  • 반복하지 마라!

    • 중복은 소프트웨어에서 모든 악의 근원이다. 많은 원칙과 기법이 중복을 없애거나 제어할 목적으로 나왔다.(60p)

  • 구조적 프로그래밍

  • 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 작성할 때는 먼저 생각을 기록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다.(61p)

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

  • 앞장에서 언급하던 내용을 함수에서도 강조하는 부분이 보인다. 오죽 중요했으면.. 이라는 생각이 들며 더 자세히 읽게 되었다. 특히, "이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다." 이 부분이 와닿았다. 내가 고민하던 부분에 대해서 위로 받는 느낌이었다.

  • 그리고, 부수 효과를 일으키지 말라! 그 외에 추상화에 대해서도 다시 한 번 생각 할 수 있었던 챕터였다. 내가 작성해왔던 함수들이 부끄러워지기도하지만 어떻게 더 발전시켜야 할지에 대해서 고민해보는것도 많은 도움이 될 것이라는 생각에 기대가 된다.

    클린코드에 나오는 내용들을 항상 명심하고 있어야겠다, 오래걸리겠지만 내 스스로가 발전할 수 있도록 계속해서 연습하고, 공부하며 익혀야겠다는 생각이 든다.

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

  • 추상화 수준이 높다? 추상화 수준이 중간이다? 추상화 수준이 낮다? 라는 문장들이 아직은 명확하게 와닿지가 않는다.

  • 추상 팩토리(Abstract Factory)?