TIL (Today I Learned)

2022.02.22 ~ 23

오늘 읽은 범위

3장. 함수

-- 내용 정리한 글

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

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

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

• 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. (p. 45)

• 근본 개념과 세부사항을 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다. (p. 46)

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

• 일반적으로 나는 switch 문을 단 한 번만 참아준다. 다형적 객체를 생성하는 코드 안에서다. 이렇게 상속 관계로 숨긴 후에는 절대로 다른 코드에 노출하지 않는다. (p. 49)

• "코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다." (p. 49)

• 이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. 함수 이름을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다. 그런 다음, 여러 단어를 사용해 함수 기능을 잘 표현하는 이름을 선택한다. 이름을 정하느라 시간을 들여도 괜찮다. 이런저런 이름을 넣어 코드를 읽어보면 더 좋다. (p. 49)

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

• 함수 선언부를 찾아보는 행위는 코드를 보다가 주춤하는 행위와 동급이다. 인지적으로 거슬린다는 뜻이므로 피해야 한다. (p. 56)

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

• 함수를 구현한 개발자는 "set" 을 동사로 의도했다. 하지만 if 문에 넣고 보면 형용사로 느껴진다. (p. 57)

• 오류 코드를 반환한다는 이야기는, 클래스든 열거형 변수든, 어디선가 오류 코드를 정의한다는 뜻이다. (p. 59)

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

• 하위 루틴을 발명한 이래로 소프트웨어 개발에서 지금가지 일어난 혁신은 소스 코드에서 중복을 제거하려는 지속적인 노력으로 보인다. (p. 61)

• 함수를 작게 만든다면 간혹 return, break, continue 를 여러 차례 사용해도 괜찮다. 오히려 때로는 단일 입/출구 규칙보다 의도를 표현하기 쉬워진다. (p. 61)

• 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 초안은 대개 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다. 내가 함수를 짤 때도 마찬가지다. 처음에는 길고 복잡하다. 들여쓰기 단계도 많고 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중복된다. 하지만 나는 그 서투른 코드를 빠짐없이 테스트하는 단위 테스트 케이스도 만든다. 그런 다음 나는 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메서드를 줄이고 순서를 바꾼다. 때로는 전체 클래스를 쪼개기도 한다. 이 와중에도 코드는 항상 단위 테스트를 통과한다. 최종적으로는 이 장에서 설명한 규칙을 따르는 함수가 얻어진다. 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라. (p. 61)

• 대가master 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다. 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어간다. (p. 62)

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

• 나는 얼마나 좋은 함수를 작성하고 있는가에 대해서 생각하게 만드는 챕터였다. 한 번에 모든 규칙을 갑자기 잘 지키거나 고치는 것은 쉽지 않겠지만 이 많은 규칙들 중에서 단 한 두 가지라도 당장 하고 있는 프로젝트를 살펴보며 수정해봐야겠다는 생각이 들었다. 내 코드가 많은 사람들에게 아름답게 읽히는 이야기가 되길 바란다.

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

• (p. 53) 삼항 함수에서 assertEquals(1.0, amount, .001) 은 어떤 점이 가치가 충분하다는 것일까

• AOP(Aspect Oriented Programming), COP(Component Oriented Programming)

• (p. 56) 부수 효과를 일으키지 마라 : 출력 인수 파트가 잘 와닿지 않았다