코드 스멜: Bloaters - 비대해진 코드 다이어트하기 🍔➡️🥗

오늘은 코드의 비만도를 측정하는 '코드 스멜' 중에서도 특히 '비대함'에 관련된 'Bloaters'에 대해 알아보려고 합니다. 👨‍💻

여러분이 일상생활에서 경험하는 것을 생각해보세요. 처음에는 깔끔했던 서랍이 시간이 지나면서 점점 물건으로 가득 차게 되죠. 코드도 마찬가지입니다!

• 처음에는 깔끔하고 간결했던 코드가 요구사항이 추가되면서 점점 비대해집니다
• 이렇게 비대해진 코드는 마치 복잡한 미로와 같아서 수정하거나 이해하기 어려워집니다

왜 필요한가?

Bloaters를 식별하고 리팩토링하는 것이 중요한 이유는 다음과 같습니다:

1. 유지보수성 향상 😌: 비대한 코드는 이해하고 수정하기 어렵습니다. 작고 명확한 코드는 유지보수가 용이합니다.
2. 버그 감소 🐞: 복잡하고 비대한 코드는 버그를 숨기기 쉽습니다. 코드가 명확할수록 버그 발견이 쉬워집니다.
3. 협업 개선 👥: 읽기 쉬운 코드는 팀원 간 지식 공유와 협업을 원활하게 합니다.
4. 확장성 개선 🌱: 잘 구조화된 코드는 새로운 기능 추가가 용이합니다.
5. 테스트 용이성 🧪: 작고 단일 책임을 가진 코드 단위는 테스트하기 쉽습니다.

기본 원리

Bloaters의 핵심 유형들을 자세히 알아볼까요?

1. Long Method (긴 메서드) ⏱️

일반적으로 10줄 이상의 코드를 포함하는 메서드는 의심해볼 필요가 있습니다.

public void processOrder(Order order) {
    // 주문 유효성 검사 (20줄)
    if (order == null) throw new IllegalArgumentException("Order cannot be null");
    if (order.getItems().isEmpty()) throw new IllegalArgumentException("Order must contain items");
    // 가격 계산 (30줄)
    double total = 0;
    for (OrderItem item : order.getItems()) {
        total += item.getPrice() * item.getQuantity();
        // 할인 적용 로직...
    }
    // 재고 확인 (25줄)
    // 결제 처리 (40줄)
    // 이메일 발송 (35줄)
    // 배송 처리 (30줄)
}

리팩토링 방법:

public void processOrder(Order order) {
    validateOrder(order);
    double total = calculateTotal(order);
    checkInventory(order);
    processPayment(order, total);
    sendConfirmationEmail(order);
    arrangeShipping(order);
}

2. Large Class (큰 클래스) 🏢

너무 많은 필드, 메서드, 코드 라인을 포함하는 클래스는 단일 책임 원칙(SRP)을 위반합니다.

public class Customer {
    // 고객 정보 관련 필드 (10개+)
    private String name, email, phone, address, city, postalCode, country;

    // 주문 관련 메서드 (5개+)
    public void placeOrder() { /* ... */ }
    public void cancelOrder() { /* ... */ }

    // 결제 관련 메서드 (8개+)
    public void makePayment() { /* ... */ }
    public void refundPayment() { /* ... */ }

    // 배송 관련 메서드 (6개+)
    // 로그인/보안 관련 메서드 (7개+)
}

리팩토링 방법:

public class Customer {
    private CustomerInfo info;
    private OrderManager orderManager;
    private PaymentProcessor paymentProcessor;
    private ShippingManager shippingManager;
    private SecurityManager securityManager;
}

3. Primitive Obsession (원시 타입 집착) 🔢

작은 객체 대신 원시 타입을 사용하거나, 상수를 통해 정보를 코딩하는 경우입니다.

public class User {
    private String phoneNumber; // "010-1234-5678" 형식의 문자열
    private int userType; // 1: 관리자, 2: 일반 사용자, 3: 게스트

    public boolean isAdmin() {
        return userType == 1;
    }
}

리팩토링 방법:

public class User {
    private PhoneNumber phoneNumber;
    private UserType userType;

    public boolean isAdmin() {
        return userType.isAdmin();
    }
}

4. Long Parameter List (긴 매개변수 목록) 📋

메서드가 3-4개 이상의 매개변수를 갖는 경우입니다.

public void createUser(String name, String email, String phone, 
                      String address, String city, String postalCode, 
                      String country, int userType, boolean isActive) {
    // 사용자 생성 로직
}

리팩토링 방법:

public void createUser(UserInfo userInfo, UserSettings settings) {
    // 사용자 생성 로직
}

5. Data Clumps (데이터 뭉치) 📦

코드의 여러 부분에서 동일한 2-3개 이상의 데이터 항목이 함께 나타나는 경우입니다.

// 클래스 1
public class Customer {
    private String city;
    private String street;
    private String zipCode;
}

// 클래스 2
public class Order {
    private String deliveryCity;
    private String deliveryStreet;
    private String deliveryZipCode;
}

리팩토링 방법:

public class Address {
    private String city;
    private String street;
    private String zipCode;
}

public class Customer {
    private Address address;
}

public class Order {
    private Address deliveryAddress;
}

실제 예제

전자상거래 시스템에서 주문 처리 로직이 있다고 가정해봅시다:

리팩토링 전

public class OrderProcessor {
    public void processOrder(String customerId, List<String> productIds, List<Integer> quantities,
                            String cardNumber, String expiryDate, String cvv,
                            String street, String city, String postalCode, String country) {
        // 100+ 라인의 복잡한 주문 처리 로직
        // 고객 정보 검증
        // 제품 정보 검증
        // 재고 확인
        // 결제 처리
        // 이메일 발송
        // 배송 처리
    }
}

리팩토링 후

public class OrderProcessor {
    private CustomerService customerService;
    private ProductService productService;
    private InventoryService inventoryService;
    private PaymentService paymentService;
    private EmailService emailService;
    private ShippingService shippingService;

    public void processOrder(OrderRequest request) {
        Customer customer = customerService.validateCustomer(request.getCustomerId());
        List<OrderItem> orderItems = productService.validateProducts(request.getItems());
        inventoryService.checkInventory(orderItems);

        Order order = new Order(customer, orderItems, request.getPaymentInfo(), request.getShippingAddress());
        paymentService.processPayment(order);
        emailService.sendConfirmationEmail(order);
        shippingService.arrangeShipping(order);
    }
}

다음은 리팩토링을 통해 개선된 점을 표로 정리한 것입니다:

Bloater 유형	리팩토링 전	리팩토링 후	개선 효과
Long Method	100+ 라인 단일 메서드	7개의 작은 메서드로 분리	코드 가독성 향상, 테스트 용이성 증가
Long Parameter List	10개 매개변수	OrderRequest 객체 하나로 통합	메서드 서명 단순화, 사용 편의성 향상
Primitive Obsession	원시 문자열/숫자 사용	PaymentInfo, Address 등 의미 있는 클래스 도입	타입 안전성 향상, 도메인 모델 명확화
Data Clumps	주소 관련 필드 중복	Address 클래스로 추출	중복 제거, 코드 응집도 향상

주의사항 및 팁 💡

⚠️ 이것만은 주의하세요!

1. 과도한 리팩토링을 피하세요

   • 모든 코드가 완벽할 필요는 없습니다. 실제로 자주 사용하는 코드에 리팩토링 노력을 집중하세요.
   • 한 번에 모든 것을 개선하려고 하지 말고, 점진적으로 개선하세요.

2. 테스트 코드가 없이 리팩토링하지 마세요

   • 리팩토링은 코드의 기능을 변경하지 않고 구조만 개선하는 것입니다.
   • 테스트 코드가 없다면, 리팩토링 후에도 코드가 올바르게 작동하는지 확인하기 어렵습니다.

3. 맥락을 고려하세요

   • 모든 상황에 일률적인 규칙을 적용하지 마세요. 때로는 짧은 메서드가 더 복잡할 수 있습니다.
   • 코드의 목적과 맥락을 고려하여 리팩토링 결정을 내리세요.

💡 꿀팁

• 정기적으로 코드 리뷰를 수행하여 Bloaters를 조기에 발견하세요. 🕵️‍♂️
• IDE의 리팩토링 도구를 활용하면 더 안전하고 효율적으로 리팩토링할 수 있습니다. 🛠️
• "점진적 개선"을 목표로 하세요. 작은 개선이라도 꾸준히 하면 큰 차이를 만들 수 있습니다. 🌱
• 코드 스멜은 절대적인 규칙이 아니라 경험적 지침입니다. 상황에 맞게 판단하세요. 🧠
• "소프트웨어 설계의 기본 원칙(SOLID)"을 학습하고 적용하면 많은 코드 스멜을 예방할 수 있습니다. 📚

마치며

지금까지 Bloaters라는 코드 스멜에 대해 알아보았습니다. 처음에는 이런 문제를 발견하고 개선하는 것이 어렵게 느껴질 수 있지만, 지속적인 관심과 개선 노력을 통해 더 나은 코드를 작성할 수 있습니다.

코드 품질은 한 번에 완성되는 것이 아니라, 지속적인 개선을 통해 이루어진다는 점을 기억하세요! 마치 건강한 식습관을 유지하는 것처럼, 코드도 꾸준한 관리가 필요합니다. 🥗

혹시 궁금한 점이 있으시거나, 다른 코드 스멜 유형에 대해 더 알고 싶으시면 댓글로 남겨주세요. 🙋‍♀️

참고 자료 🔖

• Refactoring Guru - Code Smells
• Refactoring Guru - Bloaters
• Medium - Code Smells: Bloaters
• ServiceNow - Code Smells, Refactoring Long Functions
• Medium - Code Smells with Examples: Bloaters Continued

---

#코드스멜 #Bloaters #리팩토링 #클린코드 #소프트웨어품질