TIL (Today I Learned)

2022.02.22~23

오늘 읽은 범위

3장. 함수

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

• 작게 만들어라! (p. 42~44)

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

  • 함수는 100줄을 넘어서는 안 된다. 아니 20줄도 길다.

  • if 문 / else 문 / while 문 등에 들어가는 블록은 한 줄이어야 한다는 의미이다.

  • 중첩 구조가 생길만큼 함수가 커져서는 안 된다는 뜻이다. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다.

• 한 가지만 해라! (p. 44 ~ 45)

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

  • 우리가 함수를 만드는 이유는 큰 개념을(다시 말해, 함수 이름을) 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서가 아니던가.

• 함수 당 추상화 수준은 하나로! (p. 45 ~ 47)

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

  • 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. (...) 나는 이것을 '내려가기 규칙' 이라 부른다.

  • 위에서 아래로 TO 문단을 읽어내려 가듯이 코드를 구현하면 추상화 수준을 일관되게 유지하기가 쉬워진다.

  • 본질적으로 switch 문은 N가지를 처리한다. (...) 하지만 각 switch 문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법은 있다. 물론 다형성을 이용한다.

• 서술적인 이름을 사용하라! (p. 49 ~ 50)

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

  • 함수 이름을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다. 그런 다음, 여러 단어를 사용해 함수 기능을 잘 표현하는 이름을 선택한다.

  • 이름을 붙일 때는 일관성이 있어야 한다. 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다.

• 함수에서 이상적인 인수 개수는 0개(무항)다. 다음은 1개고, 다음은 2개다. 3개는 가능한 피하는 편이 좋다. (...) 특별한 이유가 있어도 사용하면 안 된다. (p. 50)

• 부수 효과는 거짓말이다. 함수에서 한 가지를 하겠다고 약속하고선 남몰래 다른 것도 하니까. (...) 어느 쪽이든 교활하고 해로운 거짓말이다. (p.54)

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

• 오류코드보다 예외를 사용하라! (p. 57 ~ 59)

  • 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 규칙을 미요하게 위반한다.

  • 반면 오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다.

  • 오류 처리도 '한 가지' 작업에 속한다. 그러므로 오류를 처리하는 함수는 오류만 처리해야 마땅하다.

• 반복하지 마라! (p. 60)

  • 목록 3-1을 주의해서 읽어보면 네번이나 반복되는 알고리즘이 보인다.

  • 중복은 문제다. 코드 길이가 늘어날 뿐 아니라 알고리즘이 변하면 네 곳이나 손봐야 하니까. 게다가 어느 한곳이라도 빠뜨리는 바람에 오류가 발생할 확률도 네 배나 높다.

• 구조적 프로그래밍 (p.61)

  • 에츠허르 데이크스트라는 모든 함수와 함수 내 모든 블록에 입구와 출구는 하나만 존재해야 한다고 말했다.

  • goto는 절대로, 절대로 안 된다.

  • 함수를 작게 만든다면 간혹 return, break, continue의 경우엔 여러 차례 사용해도 괜찮다.

• 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 작성할 때는 먼저 생각을 기록한 후 읽기 좋게 다듬는다. (...) 내가 함수를 짤 때도 마찬가지다. 처음에는 길고 복잡하다. (p. 61)

• 나는 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메서드를 줄이고 순서를 바꾼다. 때로는 전체 클래스를 쪼개기도 한다. (p. 61)

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

• 이번 3장의 내용의 경우, 지난 내용들에서 보였던 것보다 더, 명확하게 규칙을 제안하고, 하지 말아야 할 것을 제한하도록 한다.

• 처음 예시로 들었던 코드의 길이는 상당했다. 하지만, 어느 순간 그 코드 내의 함수 기능에 집중하다 보면, 표현은 4~5줄의 코드로도 작성이 가능했다. 마지막으로 정리되어 제시된 코드는 길이가 다시 길어졌지만, 클래스와 함수의 적절한 조합으로 표현은 더욱 명확해졌으며, 어떤 기능을 함수로서 제공하고자 하였는지, 분석을 시도해 볼 수 있었다.

• 정말 다양한 규칙과 방법이 제시된 만큼, 너무도 놀라운 내용이었지만, 한편으로는 아직도 이해가 되지 않는다. 지금 이 TIL를 작성하는 이 순간에도 다음에 한 번 더 읽어내고 분석할 때는 지금보다 훨씬 정립이 되어 있기를 기도하고 있다...

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

• 추상화 수준이 아주 높다/중간이다/낮다?

• AOP, COP

• 마지막으로 이번 내용을 학습하면서 가장 어려웠던 점은 바로, '다형성'을 표현하는 것이다. 나는 Java라는 배우기만 하고, 다른 언어를 통해 코딩을 하고 있지만, 이 특징은 거의 모든 언어들에서 적용될 수 있는 특징이지 않나, 그렇기에 아직도 나는 '구조체'나 '클래스'와 같은 추상화도 내 코드에 적용하는 것을 어려워 하는데, '인터페이스'나 '추상 팩토리'와 같은 디자인 패턴과 관련되어 있는 듯한 내용이 나오면, 어떻게 이해를 해야 할지 막막하다... 실제로, 디자인 패턴이라 하는건 코딩에 아주 유용하게 적용할 수 있는 방식인 것 같은데, 이것을 어떻게 학습하고 연습해야 하는지에 대한 고민을 하게 되고, 조언도 받고 싶다.