TIL (Today I Learned)

22.02.22

오늘 읽은 범위

3장 함수

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

• p43 각 함수가 너무도 명백했다. 각 함수가 이야기 하나를 표현했다. 각 함수가 너무도 멋지게 다음 무대를 준비했다. 

  블록과 들여쓰기

  다시 말해, if문, else문, while문 등에 들어가는 블록은 한 줄이어야 한다는 의미다. 

  대게 거기서 함수를 호출한다. 

  그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록 안에서 호출하는 함수 이름을 적절히 짓는다면 코드를 이해하기도 쉬워진다. 

  이 말은 중첩 구조가 생길만큼 함수가 커져서는 안된다는 뜻이다. 

• p44 한가지만 해라!

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

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

  코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 

  다르게 표현하지면 일련의 TO문단을 읽듯이 프로그램이 읽혀야 한다는 의미다. 

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

  한 가지만 하는 작은 함수에 좋은 이름을 붙있다면 이런 원칙을 달성함에 있어 이미 절반은 성공했다. 

  함수가 작고 단순할수록 서술적인 이름을 고르지 수워진다. 

  이름이 길어도 괜찮다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 

  길고 서술적인 이름이 길고 서술적인 주석보다 좋다. 

  서술적인 이름을 사용하면 개발자 머릿속에서도 설계가 뚜렷해지므로 코드를 개선하기 쉬워진다. 

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

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

  둘 다 하면 안된다. 객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다. 

  둘 다 하면 혼란을 초래한다. 

• p58 Try/Catch 블록 뽑아 내기 

  
  try/catch 블록은 원래 추하다. 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞는다.

  그러므로 ty/catch 블록을 별도 함수로 뽑아내는 편이 좋다. 

• p61 함수를 어떻게 짜죠 ? 

  
  소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 작성할 때는 먼저 생각을 기록한 후 읽기 좋게 다듬는다.

  초안은 대게 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다음고 문장을 고치고 문단을 정리한다.

  내가 함수를 짤 때도 마찬가지다. 처음에는 길고 복잡하다.

  들여쓰기 단계도 많고 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중복된다. 하지만 그 나는 그 서투른 코드를 빠짐없이 

  테스트하는 단위 테스트 케이스도 만든다. 

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

  이와중에도 코드는 항상 단위 테스트를 통과한다. 

  •  최종적으로 이 장에서 설명한 규칙을 따르는 함수가 얻어진다. 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라 

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

• 이 장은 앞의 두 장보다 이해하기 힘들었다. 생소한 단어와 생소한 자바 언어로 인해 유독 다른 장에 비해 읽은 데 시간이 많이 걸렸던 것 같다. 도통 이해가 가지 않아 넘어갔던 부분도 많아서 중간에 이거 읽는 의미가 있을까 라는 의문감이 잠시 들었던 것 같기도 하다.

• 하지만 마지막에 '함수를 어떻게 짜죠? ' 라는 질문에 저자가 답한 부분을 보고 아까의 그 의문감 완전히 해소 됐고 읽기를 정말 잘했다 라는 확신까지 들게 만들었다.

• 저자는 소프트웨어를 짜는 행위를 글짓기에 비유하며 뭐든지 초안은 서투르기 마련이다 라고 말한다. 하지만 코드를 다듬고 중복 코드를 제거하며 더 좋은 이름으로 바꾸고 순서를 바꾸는 등 프로그래밍 퇴고의 과정을 거치며 최종적으로 이 책에서 설명하는 규칙을 따르는 코드가 만들어 진다고 말한다.

• 이 부분을 읽으며 지난 날의 내가 떠올라 부끄러웠다.

• 저자처럼 경력이 많으며 경지에 오른 사람 조차도 코드를 짜는 것에 시간을 들여 여러 차례의 수정작업을 거치는데 이제 갓 시작한 나는 얼마나 코드에 신중을 기하며 퇴고의 과정을 거쳤는가 라는 물음에 한없이 부끄러워졌다.

• 티켓을 처리하기 바빠 예상했던 대로 동작이 되는 지만 체크하여 이상이 없다면 푸쉬했던 지난 날의 난 아무도 알아보지 못하게 휘갈겨 썼던 글을 당당하게 올렸던 것은 아닐까.

• 그렇기에 함수를 잘 짜기 위한 다른 많은 방법론 보다 위의 구절이 유독 가슴에 와 닿았다.

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

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

• p47 switch문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법은 있다. 

• p47 SRP (Single Responsibility Principle)

  p48 추상팩토리