[Clean Code] 좋은 함수 설계

개발은 글짓기와 비슷하다.

 

먼저 생각을 기록한 후 읽기 좋게 다듬는 과정이 진행된다.

 

함수도 마찬가지다.

 

먼저 로직을 나열하게 추후에 리팩토링이 진행된다.

 

오늘은 구조적으로도 좋으며 읽기 좋은 함수를 만드는 방법에 대해서 알아보겠다.

 

작게 만들기

좋은 함수 구조는 대개 작게 구현하는게 좋다.

 

각 함수가 하나의 이야기를 표현하는게 좋다. 

 

보통 아래와 같은 함수의 길이 정도가 적합하다고 한다.

public static String renderPageWithSetupsAndTeardowns(
	PageData pageData, boolean isSuite) throws Exception {
    if (isTestPage(pageData))
    	includeSetupdAndTeardownPages(pageData, isSuite);
    return pageData.getHtml();
}

 

바깥을 감싸는 함수가 작아질수록 코드를 이해하기 쉬워진다.

 

 

한 가지만 하기

함수는 한 가지의 행동만 잘 하면 된다.

 

SOLID 원칙 중 '단일 책임 원칙'과 비슷한 맥락이다.

 

함수가 한 가지만 하는지 판단하는 방법으로는,

 

함수 내 로직 중 단순히 다른 표현이 아닌 의미 있는 이름으로 다른 함수를 추출할 수 없어야 한다.

 

 

 

함수당 추상화 수준은 수준을 하나로

함수 내 모든 문장의 추상화 수준이 동일해야 한다.

 

예를 들어 아래 코드를 보자.

 

public void registerUser(String username, String email, String password) {
    // 고수준 작업: 사용자 등록 로직
    if (isValidEmail(email)) {
        // 중간 수준 작업: 비밀번호 해싱
        String hashedPassword = BCrypt.hashpw(password, BCrypt.gensalt());
        
        // 저수준 작업: 데이터베이스 연결 및 쿼리 실행
        try {
            Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/mydb", "user", "pass");
            PreparedStatement stmt = conn.prepareStatement("INSERT INTO users (username, email, password) VALUES (?, ?, ?)");
            stmt.setString(1, username);
            stmt.setString(2, email);
            stmt.setString(3, hashedPassword);
            stmt.executeUpdate();
            conn.close();

        } catch (SQLException e) {
            e.printStackTrace();
        }
    } else {
        throw new InvalidEmailException("Invalid email address");
    }
}
    
private boolean isValidEmail(String email) {
    return email.contains("@");
}

 

isValidEmail()은 높은 수준으로 추상화 되어있고,

Bcrypt.haspw()는 중간 수준,

데이터베이스 연결 및 쿼리 실행은 낮은 수준이다.

 

이렇게 함수 내에 각 코드들의 추상화 수준이 제각각이라면 코드를 읽는 사람에게 혼동을 줄 수 있다.

 

public void registerUser(String username, String email, String password) 
	throws InvalidEmailException, UserRegistrationException {
    
    if (!emailValidator.isValid(email)) {
        throw new InvalidEmailException("Invalid email address");
    }

    try {
        String hashedPassword = passwordEncoder.encode(password);
        User user = new User(username, email, hashedPassword);
        userRepository.save(user);
    } catch (Exception e) {
        throw new UserRegistrationException("Failed to register user", e);
    }
}

 

위와 같이 함수 내의 추상화 수준을 동등하게 맞추는게 읽는 사람에게 좋은 코드이다.

 

 

swtich문

switch문은 특성상 작게 만들기도, 한 가지 작업을 하게 만들기도 어렵다.

 

따라서, 각 switch문을 저차원 클래스에 숨기고 반복하지 않는 방법으로 다형성(Polymorphism)을 이용할 수 있다.

 

public class AnimalSoundSystem {
    public static void main(String[] args) {
        String[] animals = {"개", "고양이", "소", "개"};

        for (String animalType : animals) {
            Animal animal = AnimalFactory.createAnimal(animalType);
            System.out.println(animalType + "의 소리: " + animal.makeSound());
        }
    }
}


class AnimalFactory {
    public static Animal createAnimal(String animalType) {
        switch (animalType.toLowerCase()) {
            case "개":
                return new Dog();
            case "고양이":
                return new Cat();
            case "소":
                return new Cow();
            default:
                throw new IllegalArgumentException("알 수 없는 동물 종류: " + animalType);
        }
    }
}

 

switch문을 구현한 추상 팩토리를 이용하여 인스턴스를 생성하면 된다.

 

하지만 switch문은 불가피하게 좋지 않은 경우로 만들게 되는 경우가 많은 것 같다.  되도록이면 쓰지 않는 것이 좋은 것 같다.

 

 

서술적인 이름을 사용

"코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다."

 

함수 이름이 아무리 길더라도 주석 대신 긴 서술적인 이름을 사용하는게 훨씬 좋다.

 

서술적인 이름을 사용한다면 설계가 뚜렷해지는 효과도 있다.

 

 

함수 인수

함수의 이상적인 인수의 개수는 0개(무항) > 1개(단항) > 2개(이항) > 3개(삼항) > 4개 이상(다항)

순으로, 적을수록 좋다.

 

4개 이상(다항)은 웬만하면 사용하지 않는 편이 좋다. 인수는 개념을 이해하기 어렵게 만들기 때문이다.

 

 

플래그 인수

일반적으로 플래그 인수는 좋지 않다.

 

특히 bool 값을 넘기는 것은 bool 값에 따라 함수가 한거번에 여러 가지를 처리한다는 것을 암시하기 때문에 좋지 않다.

 

void render(boolean isSuite)

위 함수보단

void rednerForSuite()
void renderForSingleTest()

위 함수로 나누어서 실행하는게 더 좋다.

 

 

단항 함수

단항 함수를 사용하는 경우는 크게 세 가지이다.

 

1. 인수에게 질문을 던지는 경우

boolean isUserValid(User user){}

 

2. 인수를 통해 변환하는 경우

UserResponseDto userResponseDto = UserResponseDto.from(user);

 

3.이벤트를 사용하는 경우

applicationEventPublisher.publishEvent(event);

 

위 세가지 경우가 아닌 경우라면 가급적 단항 함수를 피하는게 좋다.

 

또한 변환 함수에서 출력 인수를 사용하면 혼란을 일으킨다.

 

 

 

이항 함수

인수가 2개인 함수는 1개인 함수보다 이해하기 어렵다.

user.setName("홍길동");

setName(user, "홍길동);

 

아래보단 위 함수가 쉽게 읽히고 빨리 이해된다.

 

물론 이항 함수가 더 자연스러운 경우도 있다.

Point p = new Point(0, 0);

 

또한, 인수가 2개 이상이 되는 순간부터 그 함수를 사용할 때 인수의 순서를 인위적으로 기억해야 한다.

 

아래에 그 예시가 있다.

assertEquals(expected, actual)

 

expected와 actual은 같은 클래스이다.

 

expected 와 actual에 들어갈 값을 실수로 반대로 넣었더라도 컴파일 에러는 일어나지 않을 것이다.

 

 

인수 객체

인수가 2~3개가 필요하다면 클래스로 전달하는 것도 고려해 보아야 한다.

Circle makeCircle(double x, double y, double radius)
Circle makeCircle(Point center, double radius)

 

 

 

부수 효과를 피하기

함수에서는 약속한 한 가지만 시행해야 한다.

 

함수 내에서 예상하지 못한 작업은 시간적인 결합(temporal coupling)이나 순서 종속성(order dependency)를 초래한다.

 

public UserProfile getUserProfile(String userId) {
    UserProfile profile = userProfiles.get(userId);
    if (profile != null) {
        // 사용자 프로필 접근 시간 업데이트
        lastAccessTimes.put(userId, LocalDateTime.now());
    }
    return profile;
}

 

사용자 프로필을 가져오는 함수이지만, 내부적으로는 프로필 접근 시간 업데이트, 접근 횟수 증가 등 부수적인 효과를 가지고 있다.

 

해당 코드는 얼핏 보면 문제가 없어 보이지만, 시스템 규모가 커지고 복잡해지면 여러 문제를 야기할 수 있다.

 

public UserProfile getUserProfileAndUpdateAccessTime(String userId)

 

위와 같이 이름으로부터 함수의 모든 기능을 예측할 수 있어야 한다.

 

 

 

명령과 조회를 분리

함수는 특정 행동을 동작하거나 조회하거나 둘 중 하나만 수행해야 한다.

if (set("a", "b"))

 

여기서 set()은 a가 b로 설정되어 있는지 확인하는 함수인지, a를 b로 설정하는 함수인지 알 수 없다.

 

가장 좋은 방법은 명령 함수와 조회 함수를 분리하는 것이다.

 

if (attributeExists("username")) {
	setAttribute("username", "unclebob");
}

 

 

 

반복 피하기

public double calculateRectangleArea(double length, double width) {
    if (length <= 0 || width <= 0) {
        throw new IllegalArgumentException("길이와 너비는 양수여야 합니다.");
    }
    return length * width;
}

public double calculateCircleArea(double radius) {
    if (radius <= 0) {
        throw new IllegalArgumentException("반지름은 양수여야 합니다.");
    }
    return Math.PI * radius * radius;
}

public double calculateTriangleArea(double base, double height) {
    if (base <= 0 || height <= 0) {
        throw new IllegalArgumentException("밑변과 높이는 양수여야 합니다.");
    }
    return 0.5 * base * height;
}

 

네모, 동그라미, 삼각형을 검사하는 세 가지 함수가 있다.

 

도형(Shape)를 검사하기 위해 세 함수를 모두 사용하게 되면서 계산하는 로직이 계속 중복되게 된다.

 

public double calculateArea(Shape shape) {
    return shape.calculateArea();
}

public static void validatePositive(double value, String paramName) {
    if (value <= 0) {
        throw new IllegalArgumentException(paramName + "은(는) 양수여야 합니다.");
    }
}

 

위와 같이 validate 하는 한 함수로 만들어 통합하여 중복을 줄이는 것이 좋다.

 

 

구조적 프로그래밍

에츠허르 데이크스트라 Edsger Dijkstra의 구조적 프로그래밍 원칙에 따르면, 모든 함수와 함수 내 모든 블록에는 입구와 출구가 하나만 존재해야 한다.

 

즉, 함수의 return문은 하나여야 하고, 루프 내에서 break나 continue를 사용해는 안되고, goto는 절대로 사용하면 안된다.

 

public static int findFirstEvenGreaterThan(int[] numbers, int threshold) {
    for (int i = 0; i < numbers.length; i++) {
        if (numbers[i] <= threshold) {
            continue;
        }

        if (numbers[i] % 2 == 0) {
            return numbers[i];
        }

        if (i == numbers.length - 1) {
            break;
        }
    }

    return -1;
}

 

위 함수는 continue, break, 여러 return을 사용하는 최악의 경우일까?

 

특정 알고리즘에서 ~~인 경우에는  -1을 리턴인 경우는 많이 보았다.

 

위 규칙은 함수가 아주 클 때만 상당한 이익을 제공한다.

 

작은 함수일 경우에는 때로는 입/출구 규칙보다 의도를 표현하기 쉬워질 때가 있다.

 

출처
Clean Code: A Handbook of Agile Software Craftsmanship 
by Robert C. Martin