아래의 내용은 로버트 C. 마틴의 <클린 코드> 책을 공부하며 중요한 내용을 정리한 것입니다.
함수가 작을수록 더 좋다는 과학적인 증거나 자료는 없지만, 지난 40년간 20줄에서 3000줄까지 다양한 크기의 함수를 만들어본 저자의 경험상으로 함수는 작을수록 좋다고 한다.
함수는 100줄을 넘어서는 안되고, 20줄도 너무 길다고 한다.
함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
여기서 '한 가지'란 추상화 수준이 하나인 작업들을 뜻한다.
작게 만들어라. 그리고 한 가지만 해라.
컴퓨팅 사고의 가장 핵심이라고 할 수 있는 분할 기법에 관한 이야기인거 같다.
나도 복잡하고 어려운 문제를 작은 문제로 쪼개서 푸는걸 좋아한다. 그래야 모든 것이 명확해지고 버그가 숨어들지 않기 때문이다.
한편으로는 함수를 너무 무분별하게 쪼개면 오히려 코드 가독성을 해치지 않을까 싶기도 하다. 함수가 호출하는 함수, 또 그 함수가 호출하는 함수를 계속 찾아서 읽다보면... 지금 내가 뭘 읽고 있었는지 잊어버릴 때가 종종 있었기 때문이다.
나의 사수는 모든 로직을 한 함수 안에 구현하는걸 선호한다. 함수를 추출해서 중복된 로직을 제거할 수 있는 상황이 아니라면 함수를 잘 쪼개지 않는다. 처음엔 그런 사수의 코드 스타일이 마음에 들지 않았지만, 지금은 어느 정도 이해가 된다. 소규모의 팀에서 일하거나 혼자서 하나의 시스템을 맡아서 개발할 때는 추상화의 장점이 크게 없다. 어차피 운영 이슈가 터지면 버그를 찾기 위해서 추상화를 모두 벗겨내서 코드를 처음부터 끝까지 샅샅이 뒤져야 한다.
짧은 함수들로만 구성된 코드를 아직 읽어본 적이 없어서 판단 기준이 잘 서지 않는다.
함수 이름만 보고 그 함수가 무슨일을 하고 어떻게 사용해야 하는건지 알 수 있도록 함수 이름은 서술적으로 지어야 한다.
이름은 길어도 괜찮다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.