Clean Code - 함수

Clean Code : 함수

 

함수를 만드는 방법은 취향이라고 생각했다

 

하지만 클린코드에선 아니다

사실 함수를 만드는 방법같은건 정해져 있어야했다

이런건 프로그래밍 언어에서 함수를 처음 배울때 같이 배워야 한다

(교수님들 화이팅)

 

---

함수를 만드는 방법

 

1. 작게 만들어라!

작은함수가 좋다

일반적으로 5줄 이하여야한다

 

 

블록과 들여쓰기

if/else, while 문 등에 들어가는 블록은 한 줄이어야 한다

호출되는 블록은 함수로 감싸고, 함수 이름을 적절히 지어라

이해하기 쉬워진다

 

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

 

2. 한 가지만 해라!

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

그 한 가지를 잘 해야 한다.

그 한 가지만을 해야 한다.

 

한 가지란?

함수 이름 아래에서 추상화 수준이 한 단계인 경우

(함수란 큰 개념을 다음 추상화 수준으로 나누어 수행하기 위해서임을 명심)

 

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

한 함수 내에서 사용되는 추상화 수준은 하나로 통일해라

이게 근본 개념인지 세부사항인지 구분하기 어렵다

 

세부사항은 추가함수 내부에서 표현하자

 

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

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

'~하려면 ~한다' (TO 문단) 으로 프로그램이 읽혀야 한다

 

예)

• TO 설정 페이지와 해제 페이지를 포함하려면, 설정 페이지를 포함하고, 테스트 페이지 내용을 포함하고, 해제 페이지를 포함한다.
  • TO 설정 페이지를 포함하려면, 슈트이면 슈트 설정 페이지를 포함한 후 일반 설정 페이지를 포함한다.
  • TO 슈트 설정 페이지를 포함하려면, 부모 계층에서 "SuiteSetUp" 페이지를 찾아 include 문과 페이지 경로를 추가한다.

'~하려면 ~한다' 로 읽히도록 코드를 구현하면 추상화 수준을 일관되게 유지하기가 쉬워진다

 

 

4. 인터페이스, 다형성을 활용해라(추가)

 

 

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

 

testableHtml을 SetupTeardownIncluder로 변경되었다

 

코드를 읽으면서 짐작한 기능을 그대로 수행하도록 이름을 짓자

 

이름이 길어도 괜찮다

'길고 서술적인 이름' > '짧고 어려운 이름 + 긴 주석'

 

6. 함수 인수를 최소화 하라!

이상적인 함수 인수는 0개다

다음은 1개, 다음은 2개

3개 부터는 피하는게 좋다

 

그 이상은 사용하지 마라

인수가 있으면 함수를 이해하기 어렵다

별로 중요하지 않은 인수는 함수 안에서 만들도록 하자 

 

함수를 테스트 하는 관점에서는 더 어렵다

인수의 조합마다 테스트 케이스를 만들어야하는데

인수가 3개 이상이면 굉장히 귀찮아진다

 

 

매개 변수를 출력용도로 사용하지 말자

StringBuffer transform(StringBuffer in)이

void transform(StringBuffer out)보다 좋다

 

 

이벤트 함수는 이벤트라는 사실이 드러나도록 이름을 정하자

 

 

bool 값을 인자로 넘기는 함수는 추하다

만약 isSuite라는 bool 인자를 render 함수에 넘기고 싶으면

renderForSuite 같은 함수로 나누어서 사용하라

 

 

함수는 인자가 적을수록 직관적이다

assertEquals(message, expected, actual) 이라는 함수를 보았을때

바로 이해할수 없다

 

 

인수가 2-3개 필요하면 클래스 변수로 선언할 가능성이 있는지 짚어보자

Circle makeCircle(double x, double y, double radius);

Circle makeCircle(Point center, double radius);

 

 

함수 이름에 키워드를 추가하는 방식도 직관성을 추가한다

assertEquals보다

assertExpectedEqaulsActual(expected, actual)이 더 좋다

 

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

함수에서는 하나의 기능만 수행하고 부수적인 일을 수행하지 마라

부수 효과를 일으킨 경우 버그가 쉽게 발생하고, 이해하기가 어려워진다

 

8. 명령과 조회를 분리하라!

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

set 같은 함수에서는 반환 값이 없는게 자연스럽다

(물론 이건 golang에서는 완전히 안지켜지는 말인듯)

 

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

오류 코드는 오류가 발생한 경우 if로 바로 처리해야하지만

예외는 원래 코드에서 오류 부분이 분리되므로 깔끔하다

(이것도 golang에선...)

 

에러 코드추가를 위헤 Exception 클래스를 파생하면

재컴파일/배치 없어도 새 예외 클래스를 사용 가능

 

10. 반복하지 마라!

중복은 모든 악의 근원이다

많은 원칙과 기법이 중복을 없애기 위해 나왔다

객체 지향에서는 부모 클래스로 몰아 중복을 없앤다

중ㅈ복이 없는 코드는 가독성이 크게 높아진다

 

11. 구조적 프로그래밍

에츠허르 데이크스트라(Edsger Dijkstra)의 구조적 프로그래밍 원칙에서는

'모든 함수와 모든 블록에 입구와 출구가 하나만 존재해야 한다' 고 말했다

 

즉, return은 한 개여야하고, break, continue, goto는 사용해서는 안된다

 

하지만 함수가 작다면 return, break, continue는 별 문제가 안된다

---

"소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다"

"논문이나 기사를 작성할 때는 먼저 생각을 기록한 후 읽기 좋게 다듬는다"

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

 

책에서 나오는 내용이다

개발자는 컴퓨터뿐만 아니라 개발자들간의 소통을 위해서 프로그래밍 언어를 사용한다

당연히 언어를 이용한 코딩은 글쓰는것과 같고 함수는 문단을 만드는것과 같다

 

조잡하고, 같은말이 반복되며, 읽기 어렵고, 작가 자신만 알고 있는 이상한 문체의 소설/논문은

독자에게 지옥이다(특히 강제로 읽어야 한다면)

 

항상 우리는 글을 쓰고 있음을.

석사 시절 몇번이고 논문을 다듬고 다듬었음을.

 

염두에두고 코딩을 하도록 하자