클린 코드: 함수와 이름

나쁜 코드는 왜 비싼가

나쁜 코드는 모호한 이름, 중복, 불필요한 연산이 쌓인 코드다. 동작은 하지만 고칠 때마다 비용이 붙는다.

일정에 쫓겨 대충 쓰면 그 코드가 다음 일정을 놓치게 만든다. 코드를 건드리는 두려움은 테스트로 없앤다. 보이스카우트 규칙은 지나간 자리를 조금 더 낫게 남기는 것이다. 이름 하나, 중복 하나를 고치되, 동작 변경과 정리를 한 커밋에 섞지 않는다.

함수는 작게

함수 규칙의 출발점은 작게 만드는 것이다. 수십 줄짜리 함수는 무엇을 하는지 한눈에 들어오지 않고, 이름이 내용을 다 담지 못한다. 『클린 코드』의 예는 위키 페이지에 설정·해제 페이지를 끼워 넣는 60줄 함수를 세 단계로 줄인다.

// 줄인 결과: 무엇을 하는지만 남고, 어떻게는 아래 함수들로 내려갔다
public static String renderPageWithSetupsAndTeardowns(PageData pageData, boolean isSuite) throws Exception {
    if (isTestPage(pageData))
        includeSetupAndTeardownPages(pageData, isSuite);
    return pageData.getHtml();
}

타입 분기는 한 곳에 가둔다

직원 유형별로 급여를 계산하는 switch는 유형이 늘 때마다 커지고, 같은 switch가 isPayday, deliverPay에도 반복된다. 이는 단일 책임과 개방-폐쇄 원칙을 함께 어긴다.

// 분기는 객체를 만드는 팩터리 한 곳에서만
public class EmployeeFactoryImpl implements EmployeeFactory {
    public Employee makeEmployee(EmployeeRecord r) {
        switch (r.type) {
            case COMMISSIONED: return new CommissionedEmployee(r);
            case HOURLY:       return new HourlyEmployee(r);
            case SALARIED:     return new SalariedEmployee(r);
            default: throw new InvalidEmployeeType(r.type);
        }
    }
}
 
// 나머지 코드는 다형성으로: employee.calculatePay(), employee.isPayday()
public abstract class Employee {
    public abstract boolean isPayday();
    public abstract Money calculatePay();
}

분기는 생성 지점 한 곳, 나머지는 다형성. 새 유형이 생기면 클래스 하나와 팩터리의 case 하나만 추가된다. 설계 원칙은 SOLID 원칙 노트, 추상 클래스와 인터페이스의 선택은 추상 클래스와 인터페이스 노트에 있다.

인수와 부수 효과

• 인수는 적을수록 좋다. 0~2개가 이상적이고, 3개 이상이면 묶을 개념이 있는지 본다. makeCircle(double x, double y, double radius)보다 makeCircle(Point center, double radius)가 의도를 드러낸다.
• 불리언 플래그 인수는 "이 함수가 두 가지 일을 한다"는 신호다. 함수를 둘로 나눈다.
• 부수 효과를 숨기지 않는다. checkPassword()가 비밀번호가 맞을 때 Session.initialize()까지 호출하면, 이름만 보고 부른 사람은 세션이 지워지는 줄 모른다. 이름에 드러내거나(checkPasswordAndInitializeSession) 호출 위치를 분리한다.

명령-질의 분리

함수는 두 종류로 나눈다. 이름이 약속하지 않은 부수 효과는 다른 값을 몰래 덮어쓰는 버그가 된다.

// 나쁨: 이름은 질의인데 데이터를 바꾸고 쿠키까지 쓴다
function getFirstName() {
  const name = input.value.toLowerCase()
  document.cookie = `firstName=${name}`
  return name
}
 
// 좋음: 묻기와 바꾸기를 나눈다
function getFirstName() {
  return input.value
}
function saveFirstName(name) {
  document.cookie = `firstName=${name.toLowerCase()}`
}

함수가 무슨 일을 하는지 매번 정의를 열어 확인해야 한다면 이 원칙이 깨진 것이다. 프론트엔드 코드에 적용한 모습은 예측 가능성을 높이는 전략의 「숨은 로직 드러내기」에 있다.

처음부터 깔끔하게 쓰지 않는다

작은 함수는 처음부터 나오지 않는다. 순서가 있다.

1. 일단 동작하는 함수를 쓴다       (길고 중복도 많다)
2. 분기·경계값을 모두 덮는 테스트를 쓴다
3. 테스트를 돌리며 리팩터링한다     (쪼개기, 이름 바꾸기, 중복 제거)

3단계는 출력이 같다는 전제에서 가독성만 높이는 작업이라, 테스트가 그 전제를 지켜 준다. TDD는 이 순서를 테스트 먼저로 뒤집은 것이다.

의미 있는 이름

• 컬렉션은 복수형(members)이 기본이고, Map처럼 대체할 말이 마땅치 않으면 memberById처럼 키를 드러내는 이름이 낫다.
• 한 개념에 한 단어는 팀 단위 합의다. 프로젝트 초기에 용어집을 정해 두면 리뷰에서 이름 논쟁이 줄어든다.
• 이름이 막히면 다른 프로젝트의 관례를 찾아본다. var.gg 같은 변수명 검색 도구는 오픈소스에서 실제로 쓰는 이름·약어 후보를 보여 주고 팀 용어집을 한곳에 모으게 돕는다.
• 타입 접두사(헝가리안 표기법)를 금지하는 이 규칙과 반대로, C++ 게임 코드처럼 m·b 접두사를 표준으로 정한 팀도 있다. 어느 쪽이든 저장소 안에서 통일하는 것이 우선이다(C++ 코딩 표준과 clang-format).

피해야 할 습관

JavaScript·TypeScript로 옮길 때

같은 원칙이 JavaScript에서는 언어 기능으로 표현된다.

TypeScript에서는 여기에 타입으로 의도를 드러내는 규칙이 더해진다. strict(특히 strictNullChecks)를 켜고, 바꾸지 않을 값은 readonly·ReadonlyArray<T>·as const로 표시하고, 유니언·교차가 필요하면 type, 확장·구현할 객체 계약이면 interface를 쓴다. 세부 규칙은 TypeScript 코딩 컨벤션에 있다.

언어별 표기 규칙

이름의 표기(UpperCamelCase, lowerCamelCase, UPPER_SNAKE_CASE)와 품사 규칙(클래스는 명사, 메서드는 동사)은 언어 컨벤션이 정한다. Java는 Java 코딩 컨벤션의 「이름」 표를 따른다. 불리언 이름의 문법은 불리언 변수 이름 짓기 노트에 따로 있다.

정리

• 나쁜 코드의 비용은 쌓인다. 지나간 자리를 조금씩 낫게 남긴다.
• 함수는 작게, 한 가지만, 한 추상화 수준으로 쓰고 위에서 아래로 읽히게 배치한다.
• 타입 분기는 팩터리 한 곳에 가두고 나머지는 다형성에 맡긴다.
• 인수는 2개 이하를 목표로 하고, 부수 효과는 이름에 드러내거나 분리한다. 값을 돌려주는 함수는 아무것도 바꾸지 않는다.
• 깔끔한 함수는 동작 → 테스트 → 리팩터링 순서로 만든다.
• 이름은 의도를 드러내고, 한 개념에 한 단어를 쓰며, 타입을 넣지 않는다.

관련 노트: 결합도를 낮추는 전략, 응집도를 높이는 전략, 예측 가능성을 높이는 전략, 가독성을 높이는 전략, 불리언 변수 이름 짓기, Simple Design, 기술 부채