[클린코드] 3. 함수 - 요약 및 인사이트

인사이트 정리

처음부터 끝까지 반성하면서 봤던 파트이다.
함수의 개수를 적게 만들어야할지 함수의 길이를 적게 만들어야할지 고민이 많았는데,
다른 사람이 어떤 함수인지 바로 파악해서 고민 없이 쓸 수 있을만큼
함수를 최대한 작게 쪼개서 하나의 추상화 개념만 수행하도록 해야한다는 것을 배웠다.
함수의 규칙을 외우고 맞추기보다
다른 사람이 내가 짠 함수를 보았을 때
하나의 시나리오처럼 매끄럽게 읽히는지가 핵심이라는 것을 명심하기 !

요약

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

 

1) 작게 만들어라

- 함수를 만드는 첫째 규칙은 '작게'다. 함수를 만드는 둘째 규칙은 '더 작게'다.- 중첩구조가 생길만큼 함수가 커져서는 안 된다는 뜻이다.
-> if문 , while 문에 들어가는 블록은 한 줄이어야 한다.

 

2) 한 가지만 해라

- 함수는 한 가지를 해야한다. 그 한 가지를 잘 해야한다.
- 지정된 함수이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다.

 

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

- 함수 내 모든 문장의 추상화 수준이 동일해야한다.
- 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. 특정 표현이 근본 개념인지 세부사항인지 구분하기 어려운 탓이다.
- 내려가기 규칙 : 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다.

 

4) Switch 문

- 본질적으로 switch문은 N가지를 처리한다.
- 각 switch문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법은 있다.
- 문제상황

- 함수가 길다.
- 한 가지 작업만 수행하지 않는다.
- single responsibility principle : 코드를 변경할 이유가 여럿이기 때문이다.
- OCP : 새 유형을 추가할 때마다 코드를 변경하기 때문이다.

- 일반적으로 나는 switch문을 단 한 번만 참아준다. 다형적 객체를 생성하는 코드 아래서다.

 

5) 서술적인 이름을 사용하라

- 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.
- 여러 단어가 쉽게 읽히는 명명법을 사용한다.
- 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다.

 

6) 함수 인수

- 인수는 어렵다. 인수는 개념을 이해하기 어렵게 만든다.
- 테스트 관점에서 인수는 더 어렵다. 갖가지 인수 조합으로 함수를 검증하는 테스트 케이스를 작성한다고 상상해보라!

- 많이 쓰는 단항 형식 : 인수에 질문을 던지는 경우다. 다른하나는 인수를 뭔가로 변환해 결과를 반환하는 경우다.
- 플래그 인수 : 추하다. 함수가 한꺼번에 여러가지를 처리한다고 대놓고 공표하는 셈
- 이항함수 : 위험이 따른다는 사실을 이해하고 가능하면 단항 함수로 바꾸도록 애써야한다.
- 삼항함수 : 순서, 주춤, 무시로 야기되는 문제가 두 배이상 늘어난다. 신중히 고려하라 권고한다.
- 인수 객체 : 인수가 2-3개 필요하다면 일부를 독자적인 클래스 변수로 선언
- 인수목록 : 때로는 인수 개수가 가변적인 함수도 필요하다.
- 동사와 키워드 (1) : 단항 함수는 함수와 인수가 동사 / 명사 쌍을 이뤄야한다. ex) writeField(name)
- 동사와 키워드 (2) : 함수 이름에 키워드를 추가하는 형식이다. 즉, 함수 이름에 인수 이름을 넣는다. 그러면 인수 순서를 기억할 필요가 없어진다.

 

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

- 함수에서 한 가지만 하겠다고 약속하고선 남몰래 다른 짓도 하니까.
ex) 함수 이름만 보고 함수를 호출하는 사용자는 사용자를 인증하면서 기존 세션 정보를 지워버릴 위험에 처한다.
- 만약 시간적인 결함이 필요하다면 함수 이름에 분명히 표시한다.

 

8) 출력 인수

- 일반적으로 우리는 인수를 함수 입력으로 해석한다.
- 출력인수는 피해야한다. 함수에서 상태를 변경해야한다면 함수가 속한 객체 상태를 변경하는 방식을 택한다.

 

9) 명령과 조회를 분리하라!

- 함수는 객체 상태를 변경하거나 아니면 객체정보를 반환하거나 둘 중 하나다. 둘 다 하면 혼란을 초래한다.

 

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

- 오류코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다.
- try / catch 블록 뽑아내기 : 정상 동작과 오류 처리 동작을 분리하면 코드를 이해하고 수정하기 쉬워진다.
- 의존성 자석 : 새 오류 코드를 추가하는 대신 기존 오류코드를 재 사용한다.

 

11) 반복하지 마라
12) 구조적 프로그래밍

- 함수 내 모든 블록에 입구와 출구가 하나만 존재해야 한다고 말했다. 이는 함수가 아주 클 때만 상당한 이익을 제공한다.
- 함수를 작게 만든다면 간혹 return , break, continue를 여러 차례 사용해도 괜찮다.

13) 함수를 어떻게 짜죠?

- 처음에는 길고 복잡하다. 테스트하는 단위 테스트 케이스도 만든다.
- 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 이 와중에도 코드는 항상 단위 테스트를 통과한다.

 

14) 결론

시스템이라는 이야기를 풀어가는 데 있다는 사실을 명심하기 바란다.