[클린코드] 3장 - 함수

프로그래밍의 기술은 언제나 언어 설계의 기술이다.
소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다.

 

3장은 함수를 잘 만드는 기교를 설명한다. 이번에도 각각의 소제목을 통해서 내용을 정리하겠다. 중간중간에는 필자의 개인적인 코멘트와 편집이 들어가 있을 수 있다.

 

작게 만들어라

함수를 만드는 첫 번째 규칙: 작게. 두 번째 규칙: 더 작게. 각 함수는 작을수록 더 명확해진다. if 문 while 문 등은 한 줄이어야 한다. 중첩 구조가 생길 만큼 함수가 커져서는 안 된다. 문장이 짧으면 글을 이해하기 편하듯, 함수도 짧아야 좋다.

한 가지만 해라!

해당 소제목은 특별히 제목 2 형식을 사용했다. 정말 중요한 부분이다. 글을 쓸 때도 하나의 문단에서 하나의 주제를 가지고서 작성되듯, 함수도 하나의 작업만을 해야 이해하기 편하다. 함수는 한 가지를 해야 하며, 그 한 가지를 잘해야 한다. 그리고 그 한 가지만을 해야 한다.

 

그렇다면 한 가지가 무엇일까? 하나의 추상화 수준을 가져야 한다는 의미이다. 함수가 하나의 추상화 단계를 갖는지 확인해 보면 된다. 또 다른 방법은 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 "한 가지"를 하고 있지 않은 것이다. 마지막으로 함수를 여러 섹션으로 나눌 수 있다면 한 가지를 하고 있지 않은 것이다. 한 가지 작업만 하는 함수는 자연스럽게 섹션으로 나누기 어렵다.

Switch 문

switch문은 작게 만드는 것이 어렵다. 또한 각 case 별로 로직을 작성하기에 한 가지 작업만을 하지 않는다. 다형성을 사용하는 경우가 아니라면 절대 피해야 한다.

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

좋은 이름은 아무리 강조해도 지나치치 않는다. 코드를 읽으면서 "이 코드는 이렇게 동작하겠구나" 짐작하는 대로 동작한다면 그 코드는 깨끗한 코드라고 부를 수 있다. 이를 쉽게 하기 위해 함수를 작게 만든다면 서술적인 이름을 고르기 쉬워진다. 또한 이름을 붙이면서 이 함수가 한 가지 일을 하는지 점검이 가능하다.

 

서술적인 이름은 잘 쓰인 글처럼 개발자들 머릿속에서 물 흐르듯이 이해가 된다. 설계가 더 뚜렷해지고 어느 부분을 어떻게 개선해야 하는지 쉽게 보인다.

함수 인수

가장 이상적인 인수의 개수는 0개이다. 그다음은 1개, 다음은 2개이다. 3개는 피하는 것이 좋다. 4개부터는 특별한 이유가 있어도 사용하면 안 된다. 4개가 넘어간다면 이를 하나의 데이터 클래스로 묶어서 다루는 것을 고려해야 한다. "내 코드가 그렇게 이상한가요?"라는 책에서도 나오지만 많은 정보를 다루는 경우 그 정보를 집약해서 다루는 클래스를 생성하고 정보를 클래스의 인스턴스로 관리하는 방법에 대해 나온다.

 

플래그 인수는 추하다. 이미 이것을 사용하는 순간, 함수를 여러 가지를 처리한다는 뜻이다. True일 때, False일 때. 이는 각 케이스별로 함수를 따로 구현해야 한다.

 

만약 2개 이상의 인수를 사용해야 하며 그 인수간 순서가 보장되지 않는 경우(인수가 전혀 상관없는 두 값을 받는 경우)에는 함수 이름에 키워드를 넣어서 인자의 순서를 함수 이름을 통해 알 수 있도록 한다. 이러면 인수의 순서를 기억할 필요가 없어진다.

부수효과(Side Effect)를 일으키지 마라!

부수효과는 거짓말하는 것이다. 함수의 이름에서 짐작 가능하지 않은 일을 코드가 남몰래하는 것이다. 이는 함수를 사용할 때 많은 혼란을 불러온다. 함수를 확인하면서 이런 부수효과가 발생할 수 있는 부분을 항상 의식해야 한다.

 

이와 비슷한 경우로 인자를 출력 인자로 사용하는 것이 지양해야 한다. 함수에서 어떤 객체의 상태를 변경해야 한다면, 클래스의 메서드로 만든 뒤 메서드를 호출하는 방식으로 변경해야 한다. 그래야 불필요한 부수효과를 줄이고, 해당 데이터와 데이터를 다루는 로직을 하나의 클래스 안으로 집약시킬 수 있다.

명령과 조회를 분리하라!

함수는 객체의 상태를 변경하거나, 객체 정보를 반환하거나 둘 중 하나만 해야 한다. set이라는 함수를 동사로 의도해서 어떤 객체의 상태를 변경하도록 했다면, 그 함수는 정보를 반환해서는 안된다. 그렇게 된다면 누군가 각 해당 함수를 if 문 안에서 사용하고, 마치 해당 함수가 형용사처럼 보이게 할 수 있다.

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

예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다. 또한 여기서 더 나아가서 오류 처리를 하는 try/catch를 별도의 함수로 뽑아내면 하나의 함수가 하나의 일을 수행하도록 최종적으로 수정이 가능하다. 오류 처리도 하나의 작업임을 인식하자.

 

결론

서론에서도 적어뒀지만 프로그래밍은 글짓기와 비슷하다. 글을 쓸 때 한 번에 완벽하게 작성하는 사람은 없다. 초고를 작성하고, 거듭하여 퇴고를 거쳐 잘 짜인 글이 나온다. 우리의 함수도 처음에는 길고 복잡할 수 있다. 정돈되어 있지 않아 이해하기 어려울 수 있다. 결국 다시 다듬는 과정을 통해 분명하고 정확한 언어로 깔끔하게 맞아떨어지게 작성해야 한다. 위의 기교들을 통해 하나씩 하나씩 퇴고해 보자.