[Clean Code] 3장 - 함수

 우테코 프리코스에서 매 주마다 공통 피드백을 해주었는데 그 때마다 언급되는 피드백은 함수였다.

• 공백 라인을 의미 있게 사용한다.
• 한 함수가 한 가지 기능만 담당하게 한다.
• 함수가 한 가지 기능을 하는지 확인하는 기준을 세운다.
• 함수(메서드) 라인에 대한 기준(15라인이 넘어가지 않도록 구현한다.)

 위 사항들이 우테코 피드백 내용 중 일부분이다. 그만큼 클린 코드를 위해서는 함수를 읽기 쉽게 구현해야한다는 것을 알 수 있다.

 

작게 만들어라!

 

 프리코스를 마주하기 전 내가 지금까지 구현했던 모든 코드들은 엉망진창이었다. 15라인을 훌쩍 넘기는 것은 물론이고, 내가 구현한 코드임에도 불구하고 며칠 후에 다시 보면 무슨 의미인지도 모를 코드들이 대다수였다. 

 아무리 복잡한 요구 사항이더라도 메서드를 나누고 if/else를 지양하고 들여쓰기 수준을 줄이면 누구나 읽기 쉬운 코드로 만들 수 있음을 프리코스를 진행하며 깨달았다.

 

한 가지만 해라!

 

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

 위 문구는 책에 나온 문구이다. 정말 가슴 깊이 새겨야할 문구다. 함수가 한 가지 이상을 하는 순간 메서드의 길이는 길어지고 가독성도 떨어지게 된다.

 함수가 '한 가지'만 하는지 판단하는 방법은 다음과 같다.

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

 

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

 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. 다르게 표현하면, 일련의 TO 문단을 읽듯이 프로그램이 읽혀야 한다는 의미다.

 

함수 인수

 

 함수에서 이상적인 인수 개수는 0개(무항)다. 인수는 개념을 이해하기 어렵게 만든다. 특히 테스트 관점에서 보면 인수는 더 어렵다. 인수가 없다면 쉽게 테스트 가능하지만 인수가 많을수록 테스트 코드를 구현하기가 까다로워진다.

 실제로 프리코스에서 인수가 3개인 테스트 코드를 구현했었는데 테스트 코드 내에서 Stream<Arguments>를 반환하는 메서드를 따로 만들어 인자를 넘겨주는 방식으로 구현했다. 시간을 굉장히 많이 잡아먹었던 메서드였다.

 

 인수가 2~3개 이상으로 필욯다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어보자.

 

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

 Circle makeCircle(Point center, double radius);

 

 객체를 생성해 인수를 줄이는 방법이 눈속임이라 여겨질지 모르지만 그렇지 않다. 위 예제에서 x와 y를 묶었듯이 변수를 묶어 넘기려면 이름을 붙여야 하므로 결국은 개념을 표현하게 된다.