Temp를 Query로 대체하기: 더 깔끔하고 테스트하기 쉬운 코드를 위한 리팩토링 기법

임시 변수는 소프트웨어 코드에서 불필요한 복잡성을 야기하는 가장 흔한 원인 중 하나입니다. 이러한 변수들은 긴 메서드에 누적되고, 계산된 값에 모호한 이름을 부여하며, 변수에 저장된 로직을 추출, 테스트 또는 재사용하기 어렵게 만듭니다. 마틴 파울러가 저서 『리팩토링: 기존 코드 설계 개선』 에서 소개한 '임시 변수를 쿼리로 대체' 리팩토링은 이러한 문제를 직접적으로 해결합니다. 즉, 계산된 값을 지역 변수에 저장하는 대신, 계산 과정을 명명된 메서드(쿼리)로 추출하고, 값이 필요할 때마다 해당 메서드를 호출하는 것입니다.

그 결과, 의도를 숨기는 대신 명확하게 전달하는 코드가 만들어집니다. 더 이상 긴 메서드 맨 위에 변수 할당으로 계산 결과를 숨기지 않고, 이름과 위치를 명확히 하며 독립적으로 테스트할 수 있게 됩니다. 이 글에서는 임시 변수의 정의, 문제가 되는 경우, Java, Python, TypeScript에서 단계별 리팩토링 방법, 적용 시점과 적용하지 말아야 할 시점, 그리고 리팩토링 관련 기법과의 연관성 등 전체적인 기법을 다룹니다.

프로그래밍에서 임시 변수(Temp)란 무엇인가요?

임시 변수(일반적으로 ` temp` 라고 함 )는 함수 또는 메서드 내부에 있는 지역 변수로, 해당 범위 내에서 사용할 중간 결과를 저장합니다. 이 변수는 한 번 계산되어 이름이 지정된 변수에 저장된 후, 동일한 함수 내에서 나중에 참조됩니다. 변수는 함수 호출이 실행되는 동안에만 존재하며, 함수 외부에서는 접근할 수 없고 객체의 상태에도 저장되지 않습니다.

파이썬

# Python: base_price is a temp variable
def calculate_total(quantity, item_price):
    base_price = quantity * item_price   # temp: computed once, used below
    if base_price > 1000:
        return base_price * 0.95
    return base_price * 0.98

자바

// Java: basePrice is a temp variable
double basePrice = quantity * itemPrice;   // temp
if (basePrice > 1000) {
    return basePrice * 0.95;
}
return basePrice * 0.98;

타이프 스크립트

// TypeScript: basePrice is a temp variable
const basePrice = quantity * itemPrice;    // temp
if (basePrice > 1000) return basePrice * 0.95;
return basePrice * 0.98;

임시 변수 자체가 본질적으로 나쁜 것은 아닙니다. 비용이 많이 드는 연산의 결과를 저장하거나, 복잡한 다단계 계산을 읽기 쉬운 단계로 나누거나, 루프 반복에 걸쳐 누적되는 값을 저장하는 등 임시 변수는 정당한 용도로 사용됩니다. 문제는 이름이 지정된 메서드로 더 명확하게 표현할 수 있는 간단한 파생 값을 임시 변수에 무분별하게 사용하거나, 긴 메서드 내에서 값이 누적되어 읽는 사람이 동시에 활성화되는 여러 중간 값을 추적해야 하는 경우에 발생합니다.

소프트웨어 엔지니어링에서 리팩토링이란 무엇인가요?

리팩토링은 코드의 가시적인 동작을 변경하지 않고 기존 코드의 구조를 재구성하는 과정입니다. 목표는 코드의 내부 품질, 즉 가독성, 테스트 용이성, 유지보수성 및 모듈성을 향상시키는 것입니다. 리팩토링은 기능을 추가하거나 버그를 수정하는 것이 아니라, 코드의 기능을 유지하면서 구조를 변경하는 것입니다.

Temp를 Query로 바꾸는 것은 마틴 파울러가 설명한 수십 가지 리팩토링 기법 중 하나입니다. 이는 메서드가 너무 길거나 복잡해진 경우 이를 처리하는 기법 계열에 속합니다.

리팩토링 기법	그것이하는 일
Temp를 Query로 바꾸기	임시 변수의 계산 결과를 명명된 메서드로 추출합니다.
추출 방법	코드 블록을 추출하여 새로운 이름의 메서드로 만듭니다.
인라인 온도	간단한 임시 변수를 해당 표현식으로 직접 대체합니다.
임시 변수 분할	서로 다른 용도로 재사용되는 임시 변수를 각각 별개의 변수로 분리합니다.
루프를 파이프라인으로 대체하세요	명령형 반복문을 함수형 파이프라인(맵, 필터, 리듀스)으로 대체합니다.
설명변수 소개	복잡한 표현식을 명확히 하기 위해 명명된 임시 변수를 도입합니다.

이러한 기법들은 단독으로 사용되지 않습니다. Fowler는 임시 변수를 쿼리로 바꾸는 것이 메서드 추출 전에 필수적인 단계라고 설명합니다. 메서드에 임시 변수가 있는 경우, 추출된 부분 앞뒤에서 해당 임시 변수가 사용될 수 있기 때문에 메서드의 일부를 새 메서드로 추출하는 것이 어려워집니다. 임시 변수를 쿼리로 변환하여 먼저 제거하면 추출을 위한 준비가 완료됩니다.

임시 파일을 쿼리로 대체한다는 것은 무엇을 의미합니까?

`Temp`를 `Query`로 바꾸기는 지역 임시 변수를 메서드 호출로 변환하는 리팩토링 기법입니다. 값을 계산하여 지역 변수에 할당하는 대신, 계산 과정을 별도의 메서드인 `Query`로 분리하고, 호출 시 계산된 값을 반환합니다. `Temp`를 사용하던 모든 곳에서 해당 참조를 `Query` 메서드 호출로 대체합니다.

파울러의 리팩토링 에 나오는 대표적인 예시 :

전에:

자바

double basePrice = _quantity * _itemPrice;
if (basePrice > 1000)
    return basePrice * 0.95;
else
    return basePrice * 0.98;

후 :

자바

if (basePrice() > 1000)
    return basePrice() * 0.95;
else
    return basePrice() * 0.98;

private double basePrice() {
    return _quantity * _itemPrice;
}

쿼리 메서드 basePrice() 이제 이 메서드는 이름이 지정된 독립적인 연산 객체입니다. 클래스 내의 다른 메서드에서 호출할 수 있고, 독립적으로 테스트할 수 있으며, 하위 클래스에서 재정의할 수 있고, 호출하는 메서드를 먼저 읽지 않고도 이해할 수 있습니다.

임시 변수의 문제점

그들은 방법론 전반에 걸쳐 논리를 파편화합니다.

임시 변수는 계산을 두 부분으로 나눕니다. 하나는 값을 계산하는 할당 부분이고, 다른 하나는 값을 읽어오는 사용 부분입니다. 짧은 메서드에서는 이러한 분리가 문제가 되지 않습니다. 하지만 메서드가 30줄이나 50줄 정도로 길어지면, 할당 부분과 사용 부분 사이에 다른 여러 줄의 로직이 삽입될 수 있습니다. 독자는 할당 부분을 찾기 위해 위로 스크롤하고, 그 의미를 작업 기억에 저장한 다음, 다시 사용 부분으로 스크롤해야 합니다. 임시 변수가 추가될 때마다 이러한 인지적 부담이 가중됩니다.

추출 방법을 차단합니다

임시 변수를 사용할 때 가장 중요한 실질적인 문제는 다른 리팩토링을 방해한다는 점입니다. 예를 들어, 복잡한 조건 분기가 있는 메서드를 생각해 보세요. 이 메서드를 별도의 메서드로 분리하면 좋을 텐데, 분기에서 메서드 앞부분에 할당된 임시 변수를 사용하는 경우, 분리 과정에서 임시 변수를 매개변수로 전달하거나, 인스턴스 변수로 만들거나, 분리된 메서드 내부에서 다시 값을 계산해야 합니다. 이 세 가지 방법 모두 깔끔하지 않습니다. 하지만 임시 변수를 쿼리로 대체하여 먼저 제거하면 이러한 문제를 완전히 해결할 수 있습니다.

그들은 재사용과 변이를 유도합니다

임시 변수는 같은 메서드 내에서 여러 용도로 재사용되는 경우가 있는데, 파울러는 이러한 관행을 "임시 변수 엉킴"이라고 부릅니다. 예를 들어, 이름이 지정된 변수가 있다고 가정해 보겠습니다. temp or result 여러 번 재할당되는 변수는 의미 정보를 제공하지 않으며, 특정 시점에서 해당 변수가 무엇을 나타내는지에 대해 독자를 오도합니다. 심지어 단일 목적의 임시 변수조차도 누적되어 메서드의 범위가 독자가 동시에 추적해야 하는 중간 값으로 복잡해질 수 있습니다.

단계별 안내: 임시 데이터를 쿼리로 교체하는 방법

변환 과정은 모든 언어에서 안전하게 적용할 수 있는 네 단계를 따릅니다.

1단계: 임시 변수가 정확히 한 번만 할당되고 절대 변경되지 않는지 확인합니다. 메서드 내에서 나중에 임시 변수가 다시 할당되는 경우, 먼저 '임시 변수 분할' 기능을 사용하여 분할합니다.

2단계: 할당문의 우변을 비공개 메서드로 추출합니다. 메서드 이름은 계산 방법을 설명하는 것이 아니라 계산 내용을 설명하는 이름으로 지으세요. basePrice() 보다 더 calculateQuantityTimesPrice().

3단계: 임시 변수에 대한 모든 참조를 새 메서드 호출로 바꿉니다. 대부분의 IDE는 이 작업을 자동으로 수행할 수 있습니다. 임시 변수를 마우스 오른쪽 버튼으로 클릭하고 → 리팩토링 → 변수 인라인을 선택한 다음, 인라인된 표현식에서 메서드 추출을 클릭합니다.

4단계: 임시 변수 선언을 삭제합니다. 추출이 완료되면 임시 변수에는 더 이상 참조가 없으므로 삭제할 수 있습니다.

Java: 완벽하게 작동하는 예제

자바

// Before: Order class with temporary variables
public class Order {
    private int quantity;
    private double itemPrice;

    public double getPrice() {
        double basePrice    = quantity * itemPrice;        // temp 1
        double discountFactor;                             // temp 2
        if (basePrice > 1000)
            discountFactor = 0.95;
        else
            discountFactor = 0.98;
        return basePrice * discountFactor;
    }
}

자바

// After: temps extracted to query methods
public class Order {
    private int quantity;
    private double itemPrice;

    public double getPrice() {
        return basePrice() * discountFactor();
    }

    private double basePrice() {
        return quantity * itemPrice;
    }

    private double discountFactor() {
        return basePrice() > 1000 ? 0.95 : 0.98;
    }
}

방법 getPrice() 이제 계산 과정을 명확하게 전달하는 단일 표현식으로 읽을 수 있습니다. 추출된 각 쿼리는 독립적으로 읽고, 테스트하고, 확장할 수 있습니다. 참고로, discountFactor() 통화 basePrice()이것은 다음과 같은 이유로 옳습니다. basePrice() 이는 부작용이 없는 순수 계산이므로 두 번 호출해도 위험이 발생하지 않습니다.

Python: 임시(Temp)를 속성(Property)으로 바꾸기

파이썬에서 쿼리 메서드에 해당하는 자연스러운 표현은 다음과 같습니다. @property이를 통해 괄호 없이 메서드를 호출할 수 있으며 속성 접근과 동일하게 작동합니다.

파이썬

# Before: temporary variables in a method
class Order:
    def __init__(self, quantity, item_price):
        self.quantity   = quantity
        self.item_price = item_price

    def get_price(self):
        base_price     = self.quantity * self.item_price  # temp
        discount       = 0.95 if base_price > 1000 else 0.98  # temp
        return base_price * discount

파이썬

# After: temps replaced with properties (query methods in Python)
class Order:
    def __init__(self, quantity, item_price):
        self.quantity   = quantity
        self.item_price = item_price

    def get_price(self):
        return self.base_price * self.discount_factor

    @property
    def base_price(self):
        return self.quantity * self.item_price

    @property
    def discount_factor(self):
        return 0.95 if self.base_price > 1000 else 0.98

사용 @property 방법 self.base_price 인스턴스 변수와 동일하게 읽히므로 호출 코드가 self.base_price * self.discount_factor 완전히 자연적입니다. 각 속성은 독립적으로 테스트할 수 있습니다.

파이썬

def test_base_price():
    order = Order(10, 150)
    assert order.base_price == 1500

def test_discount_factor_high_value():
    order = Order(10, 150)   # base_price = 1500 > 1000
    assert order.discount_factor == 0.95

def test_get_price():
    order = Order(10, 150)
    assert order.get_price() == 1500 * 0.95

임시 변수 기반 버전으로는 이러한 수준의 테스트가 불가능합니다. 내부 계산 때문입니다. base_price discount_factor 해당 메서드 외부에서는 접근할 수 없습니다.

TypeScript: 쿼리 메서드 및 게터

TypeScript는 메서드 기반 쿼리와 속성 getter를 모두 지원하며, 이는 각각 Java와 Python에서 사용 가능한 패턴과 일치합니다.

타이프 스크립트

// Before: temporary variables
class Order {
    constructor(private quantity: number, private itemPrice: number) {}

    getPrice(): number {
        const basePrice = this.quantity * this.itemPrice;  // temp
        const discount  = basePrice > 1000 ? 0.95 : 0.98; // temp
        return basePrice * discount;
    }
}

타이프 스크립트

// After: TypeScript getters replace temps
class Order {
    constructor(private quantity: number, private itemPrice: number) {}

    getPrice(): number {
        return this.basePrice * this.discountFactor;
    }

    private get basePrice(): number {
        return this.quantity * this.itemPrice;
    }

    private get discountFactor(): number {
        return this.basePrice > 1000 ? 0.95 : 0.98;
    }
}

쿼리 메서드 이름 지정하기

쿼리 메서드의 이름은 가장 중요한 역할을 합니다. 이름이 잘못된 추출 메서드는 대체된 임시 메서드보다 더 나쁩니다. 왜냐하면 불투명한 간접 참조를 생성하기 때문입니다. 호출자는 메서드 정의를 찾아봐야만 해당 메서드가 무엇을 하는지 이해할 수 있으므로 추출의 목적이 무의미해집니다.

좋은 쿼리 메서드 이름은 다음 원칙을 따릅니다.

계산 방법이 아니라 무엇을 나타내는지 설명하십시오. basePrice() 사업 개념을 전달합니다. getQuantityTimesItemPrice() 이 설명은 개념이 아닌 계산 과정을 나타냅니다. 계산 방식이나 개념 이름이 변경될 때 이 구분이 중요해집니다. basePrice() 공식이 바뀌더라도 안정적으로 유지됩니다.

값을 나타낼 때는 명사구를 사용하세요. 쿼리 메서드는 값을 반환하며, 명령이 아닙니다. discountFactor(), totalAmount(), isEligible() 반환되는 값의 이름을 지정하는 관례를 따르십시오. calculateDiscount(), processAmount() 명령형 규칙을 따르기 때문에 순수하게 계산하고 반환하는 메서드에는 혼란을 초래할 수 있습니다.

부울 쿼리는 질문 형태로 읽어야 합니다. isHighValue(), hasDiscount(), meetsThreshold() 반환값이 부울 값이며 호출자가 예/아니오 질문을 하고 있음을 전달합니다. bool 変数名 (부울 변수 이름 지정, 검색 콘솔 데이터의 쿼리)는 바로 이러한 우려를 반영합니다. 부울 변수와 메서드는 사용 시점에 그 의미가 명확해지는 이름을 가져야 합니다.

관련 메서드 전반에 걸쳐 이름을 일관되게 유지하세요. If basePrice() 사용 discountFactor()명명법의 일관성은 독자들에게 다음을 알려줍니다. discountFactor 에 따라 달라집니다 basePrice명명 규칙이 일관되지 않으면 이러한 암묵적인 문서화가 깨집니다.

임시 파일을 쿼리로 대체하는 시점은 언제인가요?

다음과 같은 경우에 이 리팩토링을 적용하세요:

• 임시직은 딱 한 번만 배정되며 다시 배정되지 않습니다.
• 이 계산은 순수한 표현식입니다. 필드나 매개변수에서 값을 읽어오지만 외부 상태를 수정하거나 네트워크 서비스를 호출하거나 시간이나 무작위성에 의존하지 않습니다.
• 계산 과정이 너무 복잡하면 이름을 붙이는 것이 가독성을 높이는 데 도움이 될 수 있고, 너무 간단하면 임시방편으로 이름을 붙이는 것만으로 충분할 수 있습니다.
• temp를 사용하는 블록에 Extract Method를 적용하려고 합니다.

가장 일반적인 이상적인 시나리오는 파생 값입니다. 예를 들어 가격, 합계, 할인, 형식화된 문자열, 조건부 분류 등이 있습니다. 이러한 값들은 객체의 필드에서 완전히 파생되며 부작용이 없으므로 메서드 내부의 중간 계산이 아닌 객체의 속성으로 자연스럽게 간주됩니다.

임시 대체 방법을 쿼리로 적용하지 않아야 하는 경우

성능에 민감한 작업. 데이터베이스 쿼리, 네트워크 호출, O(n²) 루프와 같이 계산 비용이 많이 드는 작업의 경우, 쿼리 메서드를 두 번 호출하면 비용이 두 배로 증가합니다. 임시 변수는 바로 이러한 문제를 방지하기 위해 존재합니다. 이러한 경우에는 임시 변수를 그대로 두거나 쿼리 메서드를 메모이제이션(첫 번째 호출 후 결과를 캐시)하는 것이 좋습니다.

파이썬

# Memoized property: computed once, cached
from functools import cached_property

class Order:
    @cached_property
    def expensive_validation(self):
        return self.external_service.validate(self.data)  # called once, cached

부작용을 일으키는 작업. 임시 변수에 한 번만 실행되어야 하는 작업(고유 ID 생성, 로깅, 파일 쓰기 등)의 결과가 저장되는 경우, 이를 쿼리로 변경하면 호출될 때마다 해당 작업이 실행됩니다. 이는 프로그램의 구조뿐만 아니라 동작 방식까지 변경하는 것입니다. 부작용을 일으키는 임시 변수에는 이러한 리팩토링을 적용하지 마십시오.

반복문 실행 동안 누적되는 온도. 온도는 누적되는 온도입니다. for 루프 total += item.price`Project Temp`는 `Replace Temp with Query`의 대상이 아닙니다. `Project Temp`는 파생 값이 아니라 반복을 통해 누적되는 상태입니다. 루프가 문제라면 `Replace Loop with Pipeline`을 고려해 보세요.

관련 리팩토링 기법

`Replace Temp with Query`는 메서드에서 불필요한 복잡성을 제거하는 데 사용되는 기법 계열에 속합니다. 이러한 기법 계열을 이해하면 개발자는 당면한 문제에 적합한 기법을 선택하는 데 도움이 됩니다.

Extract Method는 가장 흔하게 함께 사용되는 기능입니다. Replace Temp with Query를 사용하면 추출된 부분과 메서드의 나머지 부분 사이에서 어색한 매개변수 전달이 필요한 변수를 제거하여 Extract Method를 사용할 수 있게 됩니다.

인라인 임시 변수는 임시 변수를 도입하는 것과 반대로, 임시 변수를 해당 표현식으로 코드 내에서 직접 대체합니다. 임시 변수가 코드의 가독성을 높여주지 않고 해당 표현식이 이미 읽기 쉬운 경우에 인라인 임시 변수를 사용하십시오.

임시 변수 분할은 동일한 메서드 내에서 하나의 임시 변수가 여러 용도로 재사용될 때 적용됩니다. 각 용도를 반영하는 이름으로 별도의 변수로 분할한 다음, 결과로 생성된 일회용 임시 변수 중 하나에 쿼리로 임시 변수 바꾸기를 적용합니다.

설명 변수를 도입하는 것은 정반대의 접근 방식입니다. 복잡한 표현식이 읽기 어려울 경우, 설명적인 이름을 가진 임시 변수를 도입하면 가독성을 높일 수 있습니다. 이 기법과 임시 변수를 쿼리로 대체하는 기법은 서로 상충 관계에 있으므로, 개발자는 특정 코드에 어떤 방향이 더 적합한지 판단해야 합니다.

루프를 파이프라인으로 대체하세요 임시 누적기를 사용하는 루프를 연결된 파이프라인 연산으로 대체할 수 있는 일반적인 패턴을 다룹니다.map, filter, reduce)이 더 명확하고 읽기 쉽습니다.

방법 SMART TS XL 대규모 리팩토링을 지원합니다.

`Replace Temp with Query`는 로컬 리팩토링입니다. 즉, 메서드 내의 변수 하나를 변경하는 것입니다. 하지만 규모가 큰 코드베이스에서는 "이 리팩토링을 어떻게 적용할까?"라는 질문보다 "코드베이스 전체에서 어디에 적용해야 하며, 적용했을 때 어떤 부분이 영향을 받을까?"라는 질문이 더 중요합니다.

SMART TS XL 이 도구는 코드베이스 전반에 걸친 구조적 분석을 제공하여 이 질문에 체계적으로 답할 수 있도록 합니다. 동일한 계산이 여러 위치에서 임시 변수로 수행되는 부분을 식별하고, '임시 변수를 쿼리로 대체' 기능이 단일 명명된 쿼리 메서드로 통합하도록 설계된 패턴을 파악합니다. 또한 리팩토링된 쿼리 메서드가 추출된 후 어떻게 사용되는지 추적하여 리팩토링이 수행되기 전에 리팩토링 범위를 확인할 수 있도록 합니다. 이 도구는 다양한 언어에서 작동합니다. COBOL 프로그램, Java 서비스, Python 파이프라인이 모두 동일한 데이터를 사용하는 엔터프라이즈 시스템에서도 사용할 수 있습니다. 정적 코드 분석 영향 분석 서로 다른 언어에서 동일한 논리적 계산이 다른 형태로 나타나는 부분을 식별하는 것이 바로 "임시 변수를 쿼리로 대체" 기능이 단일 언어 수준에서 해결하는 근본적인 문제입니다.

다음 작업을 수행하는 팀을 위해 레거시 현대화, SMART TS XL의 종속성 시각화 이를 통해 리팩토링된 구성 요소가 변경하기 전에 어디에서 사용되는지 확인할 수 있으므로, 계산을 쿼리 메서드로 추출하더라도 원래 구조를 예상했던 호출자가 오류를 일으키지 않도록 할 수 있습니다.

임시 변수와 자체 설명 코드

임시 변수를 쿼리로 대체할지 여부는 궁극적으로 코드가 무엇을 전달해야 하는지에 대한 결정입니다. 임시 변수는 구현 방식을 전달합니다. 즉, 이 값을 얻기 위해 수행한 계산 과정을 나타냅니다. 반면 쿼리 메서드는 도메인을 전달합니다. 즉, 이 값이 의미하는 바를 나타냅니다. Order 클래스에서, basePrice() 이는 독자에게 해당 개념이 그 영역에 존재한다는 것을 알려줍니다. double x = quantity * itemPrice 독자에게 산술 연산에 대해 알려줍니다.

코드가 발전함에 따라 도메인 개념은 안정적인 위치를 필요로 합니다. 임시 변수에 포함된 계산은 변경될 수 있고, 여러 메서드에서 중복될 수 있으며, 다음에 코드를 읽는 개발자가 오해할 수도 있습니다. 반면, 명명된 쿼리 메서드는 찾기 쉽고, 테스트 가능하며, 문서화되고, 의도적으로 발전될 수 있습니다. 이러한 안정성은 계산이 필요한 모든 곳과 해당 메서드를 사용할 모든 개발자에게 걸쳐 유지되어야 합니다. 이것이 바로 임시 변수를 쿼리 메서드로 바꾸는 것이 단순한 구문 변경 이상의 의미를 갖는 이유입니다. 이는 코드베이스가 해결하는 문제를 어떻게 전달할지에 대한 결정입니다.