FunctionLength

내 경력에서 함수의 길이는 어느 정도여야지? 라는 논란을 자주 들었다. 이것은 더 중요한 물음으로 대체할 수 있다. 그것은 어느 정도 길이의 코드가 되면 그것을 함수로 삼아야 하느냐는 것이다.

몇 가지 가이드 라인에서는 한 화면에 잡히지 않는다면, 이 밖에도 재이용 할지 여부를 기본으로 두 번 이상 반복 처리하면 함수로 해야 한다, 아니면 그대로 인라인으로 두자는 것도 있다.

그러나 내가 가장 알맞다고 생각하는 것은 의도와 구현의 분리라는 것이다. 만약 무엇을 해야 하는지 이해하고 있어서 신경 써야 하는 코드 한 부분이 있다면 이곳을 함수로서 꺼내서 이 “무엇”을 딴 이름을 붙여 버리는 것이다.

이렇게 하면 다시 이 코드를 읽을 때에 이 코드의 목적이 바로 눈에 들어올 것이고, 이 함수가 하려고 있는 것, 즉 함수 자체에 주의를 기울일 필요는 없을 것이다.

나는 이 규율을 채용한 뒤 짧은 함수를 쓰게 되었다. 보통 몇 줄이다. 코드가 6 행을 넘으면 이젠 나는 함수의 냄새를 느끼기 시작하고, 1 행 코드로 되는 함수도 드물지 않다.

사실 코드의 크기가 중요한 것은 아니라는 생각은 켄트 벡이 오리지널 Smalltalk 시스템에서 실례로 보여주었다. 당시 Smalltalk는 흑백 디스플레이에서 동작하고 있었으므로 텍스트나 그래픽을 하이라이트 표시하려면 화상을 반전시키기 것으로 구현하였다. 그리고 Smalltalk의 화상 클래스에는 이 “Highlight”(하이라이트)로 불리는 메소드가 있으며 이 구현은 단순히 “reverse” 메소드를 호출하는 것이었다.

이 명칭은 구현보다 길었지만 코드의 의도와 코드 구현 사이에는 큰 거리가 있었기 때문에 그리 큰 문제가 아니었다.

함수의 호출 비용에 의한 성능 열화를 걱정하여 짧은 함수에 우려를 표하는 사람들이 있다. 내가 아직 젊었을 때는 자주 그런 요소도 있었지만 현재는 거의 없을 것이다. 최적화된 컴파일러라면 짧은 함수는 캐시 하기 쉽기 때문에 보다 적절히 다루게 되었다.

지금까지와 마찬가지 성능 최적화에 관한 일반적인 가이드 라인은 중요하다. 때로는 함수를 나중에 인라인으로 변환할 필요가 있을 수 있다. 한편 작은 함수는 성능 향상을 위한 다른 선택을 자주 일러 준다.

나는 일반적인 관용구로서 리스트 메소드에 aList.length==0 을 사용하여 isEmpty 메서드의 사용에는 반대하는 사람들을 본 적이 있다. 그러나 함수의 의도를 분명히 나타낸 함수 이름을 사용하면 컬렉션이 비어 있음을 판정하는 것이 길이를 판정하기보다는 고속이라면 이를 지원할 수 있게 된다.

이렇게 작은 함수는 이름이 좋은 경우에만 기능하므로 이름을 붙일 때는 주의를 기울일 필요가 있다. 여기에는 연습이 필요하지만 일단 숙달하면 이 방법으로 코드를 고도로 자기 문서화할 수 있다. 더 큰 스케일에서 보면 함수는 이야기처럼 읽는 것처럼 읽을 수 있고, 필요할 때 어떤 함수를 자세히 읽어 나갈지 선택할 수 있게 된다.

출처: http://www.publickey1.jp/blog/17/post_262.html