3. 함수

작게 만들어라

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

함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다.

당연한 말이지만, 그래야 함수는 읽고 이해하기 쉬워진다.

한 가지만 해라

함수는 한 가지를 해야 한다.

그 한 가지를 잘 해야 한다.

그 한 가지만을 해야 한다.

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

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

한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다.

특정 표현이 근본 개념인지, 아니면 세부사항인지 구분하기 어려운 탓이다.

그리고 구분하기 어려워지면 세부사항에 세부사항을 더 붙이는 복잡한 함수가 된다.

위에서 아래로 내려가기 규칙

코드는 위에서 아래로 이야기처럼 읽혀야 좋다.

한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다,

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

서술적인 이름을 사용하라

testableHtml -> SetupTeardownIncluder 좋은 이름이 주는 가치는 강조해도 모자르지 않다.

함수 인수

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

다음은 1개, 다음은 2개이다. 3항은 가능하면 피하는 것이 좋고, 4항 이상일 경우에는 특별한 이유가 필요하다.

그리고 특별한 이유가 있어도 사용하길 지양한다.

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

함수에서 한 가지를 하겠다고 약속하고선 남 몰래 다른 일을 한다.

이는 때로 예상치 못한 변수가 발생할 수 있다.

명령과 조회를 분리하라

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

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

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

if 를 사용해서 오류 코드를 뽑아 처리하기 보다는 try/catch 문을 사용해라,

하지만 try/catch 문도 하나의 함수 안에 정상 동작과 오류 동적을 뒤섞기 때문에 catch 부분을 별도의 함수로 뽑아 내는 편이 좋다.

반복하지 마라

(DRY : Don't Repeat Yourself)
코드 길이가 늘어날 뿐만 아니라 하나의 알고리즘이 변하면 네 곳이나 손봐야 한다.

게다가 오류가 발생할 확률도 몇 배나 높다.

결론

시스템은 풀어나가야할 하나의 큰 이야기라고 할 수 있다.

함수를 잘 만드는 기교도 중요하지만,

분명하고 정확한 언어로 깔끔하게 맞아떨어져야 이야기를 풀어나가기가 쉬워진다는 사실 또한 기억해야 한다.

사견을 덧붙이면…?

이번 장은 함수에 대한 얘기였다. 주 언어가 자바인 나에게는 메소드 라고 할 수 있을 것 같다.

읽으면서 가장 기억에 남는 부분은 아무래도 함수 인수 이 부분인데, 이유인 즉

전 회사에서 코어를 담당하는 메소드의 파라미터가 무려 10개 였다!!!

길이도 길어서 볼 때마다 어려운 코드였고, 아에 대놓고 null 이 들어가는 인수도 있었다.

정말 이해하기 힘들고 어려워서 항상 저걸 쪼개고 싶다는 생각을 했는데…

테스트도 없고 그 부분을 건드릴 깜냥(?)이 안되서 결국 나올 때까지 못 건드리고 나왔다.

그 후에는 유닛 테스트도 진행하고 나름 재밌게 하고 있다.

책에서도 나오지만 유닛테스트를 하다보면 assertEqual() 을 사용할 때가 있다. expected 와 actual 의 순서가 헷갈리곤 하는데

다행이도 인텔리 제이에서는 파라미터에 대한 설명(?) 이랄까 그런게 잘 나오더라