클린 코드 대신 읽어드립니다 _ 3. 함수 (정리, 요약, 후기)

 

1. 작게 만들어라!
함수를 만드는 첫쨰 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다.

 

 

 

 

 

 

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

 

 

 

 

 

 

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

코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 즉, 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. 나는 이것을 내려가기 규칙이라 부른다.

 

 

 

 

 

 

 

 

3. 서술적인 이름을 사용하라

testtableHtml 보다는 SetupTeardownIncluder.render

: 함수가 하는 일을 좀 더 잘 표현하므로 훨씬 좋은 이름이다.

 

이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려움 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. 함수 이름을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다. 그런 다음, 여러 단어를 사용해 함수 기능을 잘 표현하는 이름을 선택한다.

 

이름을 정하느라 시간을 들여도 괜찮다. 이런저런 이름을 넣어 코드를 읽어보면 더 좋다. 이클립스나 인텔리제이 같은 최신 IDE에서 이름 바꾸기는 식은 죽먹기다. IDE를 사용해 이런저런 이름을 시도한 후 최대한 서술적인 이름을 골라도 좋겠다.

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

 

includeSetupPages, includeSuiteSetupPage, includeSetupPage 등이 좋은 예다. 문체가 비슷하면 이야기를 순차적으로 풀어가기도 쉬워진다. 방금 열거한 함수를 살펴보라. 당장 이런 질문이 떠오르리라. " includeTeardownPages, includeSuiteTeardownPage, includeTeardownPage도 있나요?" 당연하다. '짐작하는 대로'다.

 

 

 

 

 

 

 

 

4. 함수 인수

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

 

코드를 읽는사람에게는 includeSetupPageInto(new PageContent)보다 includeSetupPage()가 이해하기 더 쉽다. includeSetupPageInto(newPageCOntent)는 함수 이름과 인수 사이에 추상화 수준이 다르다. 게다가 코드를 읽는 사람이 현 시점에서 별로 중요하지 않은 세부사항, 즉 StringBuffer를 알아야 한다.

 

 

 

 

 

 

 

5. 플래그 인수

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

 

 

 

 

 

 

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

기존

 

 

변경 후 (1)

 

변경 후 (2)

 

 

 

 

 

 

 

 

7. 함수를 어떻게 짜죠?

소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 작성할 떄는 먼저 생각을 기록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다.

 

내가 함수를 짤 때도 마찬가지다. 처음에는 길고 복잡하다. 들여쓰기 단계도 많고 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중복된다. 하지만 나는 그 서투른 코드를 빠짐없이 테스트하는 단위 테스트 케이스도 만든다.

 

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

 

 

 

 

 

 

 

 

결론

대가master 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다.

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