리팩터링이란 코드의 외부 동작은 동일하지만 내부의 구조를 개선하기 위해 소프트웨어를 수정하는 것입니다. 리팩터링을 하면 코드 작성 후에 체계적으로 설계된 코드로 바꿀 수 있습니다. 리팩터링에 따라 설계가 개선되면 결과적으로 개발비용 감소에 따른 경제적 효과가 발생합니다.

•

리팩터링 vs 성능개선

: 두 접근 모두 소프트웨어의 내부 구조에 변화를 주지만 외부 동작 방식에는 변화를 주지 않습니다.

: 리팩터링의 목적은 소프트웨어를 쉽게 읽고 수정할 수 있도록 변경하는 것입니다. 반면 성능개선의 목적은 소프트웨어의 성능을 높이는 것입니다. 리팩터링에 따라 코드가 정리된 후에 성능개선 작업을 하는 것을 권합니다. 성능개선만을 목적으로 작업하다보면 종종 코드가 더욱 복잡해질 수 있습니다.

2) 리팩터링의 효과

•

다양한 변화에 대응할 있는 구조를 다질 수 있습니다.

: 잘 설계된 소프트웨어도 요구사항 변경에 따라 코드가 지속 수정되면, 시스템의 무결성이 망가지고 기존 설계가 무너지기 마련입니다.

: 설계 작업이 완료되어도 구현에 들어가면 필연적으로 기존 설계와 다른 부분이 생깁니다.

•

구현 시 버그가 발생해도 바로 잡는 것이 상대적으로 쉽습니다.

: 리팩터링은 기본적으로 코드를 작은 조각으로 만들기 때문에 에러 발생부분에 대해 상대적으로 쉽게 포착할 수 있습니다.

•

소프트웨어 유지보수 비용을 낮춥니다.

: 협업자가 소프트웨어를 쉽게 이해할 수 있고 쉽게 수정할 수 있기 때문에 팀 단위의 능률을 높입니다.

: 시간이 지남에 따라 구조가 망가지는 것을 방지할 수 있기 때문에 소프트웨어

3) 리팩터링이 특히 필요한 시점

리팩터링은 항상 하는 것입니다. 리팩터링만을 위해 따로 시간을 내서 하는 것이 아닙니다.

•

새로운 기능을 추가하는 시점에 더욱 신경 써서 리팩터링을 해야 합니다.

: 새로운 기능을 추가하면 에러 발생 가능성이 높습니다. 리팩터링하여 코드를 명확히 만들면 새로운 기능 추가에 따른 에러 발생 가능성을 낮출 수 있습니다.

•

해결이 안되는 버그가 있을 때 리팩터링하면 버그의 위치를 쉽게 찾을 수 있습니다.

: 대체로 버그의 위치를 쉽게 찾을 수 없는 이유는 코드를 쉽게 읽을 수 없기 때문입니다.

•

팀원에게 코드 리뷰를 받기 전에 리팩터링하면 더욱 가치 있는 코멘트를 받을 수 있습니다.

: 남의 코드를 읽는 것은 일반적으로 힘들고 때로는 귀찮은 일입니다. 만약 리뷰 대상이 되는 코드가 깔끔하게 정리되어 있다면, 더욱 원활하고 생산적인 코멘트를 받을 수 있습니다.

나. Bad Smells in Code

리팩터링이 절실한 코드에는 일정한 패턴이 있습니다.

1) 기이한 이름(Mysterious Name)

•

코드의 이름이 단순 명료하지 않습니다.

2) 중복 코드(Duplicated Code)

•

동일한 코드 조각이 여러 곳에 존재합니다.

fun calculateSalesTax(amount: Double): Double {
    return amount * 0.08
}

fun calculateServiceTax(amount: Double): Double {
    return amount * 0.08
}
Kotlin
복사

3) 긴 함수(Long Function)

•

하나의 함수에 너무 긴 로직이 존재합니다.

fun calculateTotal(cart: List<Product>): Double{
    var total = 0.0

		// caculate sub tottal
    for (product in cart) {
        total += product.price
    }

		// apply discount 
    if (total > 100) {
        total -= total * 0.1
    }

		// add sales tax
    val tax = total * 0.08
    total += tax

    return total
}
Kotlin
복사

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

•

함수 시그니처에 너무 많은 매개변수가 존재합니다.

5) 전역 데이터(Global Data)

•

코드베이스의 모든 곳에 접근할 수 있는 전역 데이터가 존재합니다. 

6) 가변 데이터(Mutable Data)

•

변경에 따라 부수작용이 발생할 수 있는 가변 데이터가 존재합니다. 

7) 뒤엉킨 변경 (Divergent Change)

•

여러 관심사에 따라 하나의 객체가 자주 변경됩니다.

data class Address(var street: String, var city: String, var state: String, var zip: String)

data class Order(var id: Int, var product: String, var quantity: Int)

class UserProfile {
    var username: String = ""
    var email: String = ""
    var address: Address = Address("", "", "", "")
    var orders: MutableList<Order> = mutableListOf()

    // Method related to user profile management
    fun changeUsername(newUsername: String) {
        username = newUsername
    }

    // Method related to address management
    fun changeAddress(newAddress: Address) {
        address = newAddress
    }

    // Method related to order management
    fun placeOrder(newOrder: Order) {
        orders.add(newOrder)
    }
}
Kotlin
복사

8) 산탄총 수술 (Shotgun Surgery)

•

동일한 코드 조각이 여러 관심사에 분산되어 있습니다.

class OrderConfirmation {
    fun sendOrderConfirmationEmail(order: Order) {
        // Send order confirmation email
    }
}

class OrderHistory {
    fun sendOrderConfirmationEmail(order: Order) {
        // Send order confirmation email
    }
}

class OrderStatus {
    fun sendOrderConfirmationEmail(order: Order) {
        // Send order confirmation email
    }
}
Kotlin
복사

9) 기능 편애 (Feature Envy)

•

객체 내 일부 속성이 다른 객체에서 자주 사용됩니다.

class Customer(
    val name: String,
    val age: Int,
    val address: Address
)

class Order(
    val customer: Customer,
    val items: List<Item>
) {
    fun calculateTotal(): Double {} { /*...*/ }

    fun printCustomerDetails() {
        println("Customer Name: ${customer.name}")
        println("Customer Age: ${customer.age}")
        println("Customer Address: ${customer.address}")
    }
}
Kotlin
복사

10) 데이터 뭉치 (Data Clumps)

•

대부분의 경우 함께 사용되는 데이터의 조합이 존재합니다.

class Order(
    private val orderNumber: String,
    private val customerName: String,
    private val customerEmail: String,
    private val customerAddress: Address,
    private val items: List<Item>
) {
    // ... other methods and logic ...
}

class Address(
    val street: String,
    val city: String,
    val state: String,
    val zipCode: String
)

class Item(
    val name: String,
    val price: Double
)
Kotlin
복사

11) 기본형 집착 (Primitive Obsession)

•

요구사항을 만족하는 객체를 정의하지 않고 기본형 타입을 사용합니다.

data class User(
	val name: String, 
	val email: String, 
	val phoneNumber: String
)
Kotlin
복사

개선

12) 반복되는 switch문 (Repeated Switches)

•

케이스를 추가해야 한다면 switch문이 존재하는 모든 곳에서 연관 케이스를 함께 추가해야 합니다.

enum class AnimalType {
    DOG, CAT, BIRD
}

class Animal(val type: AnimalType) {
    fun makeSound() {
        when (type) {
            AnimalType.DOG -> println("Woof!")
            AnimalType.CAT -> println("Meow!")
            AnimalType.BIRD -> println("Tweet!")
        }
    }

    fun eat() {
        when (type) {
            AnimalType.DOG -> println("Dog is eating...")
            AnimalType.CAT -> println("Cat is eating...")
            AnimalType.BIRD -> println("Bird is eating...")
        }
    }
}
Kotlin
복사

개선

13) 반복문(Loops)

•

코드의 의도를 쉽게 파악할 수 없는 반복문을 사용하고 있습니다. 

fun sumOfPositiveNumbers(numbers: List<Int>): Int {
    var total = 0
    for (number in numbers) {
        if (number > 0) {
            total += number
        }
    }
    return total
}
Kotlin
복사

개선

14) 성의 없는 요소(Lazy Element)

•

빈약한 기능으로 정의된 객체가 존재합니다.

class UserName(val name: String)

fun printUserName(userName: UserName) {
    println(userName.name)
}

val user = UserName("John Doe")
printUserName(user) // Outputs: John Doe
Kotlin
복사

15) 추측성 일반화 (Speculative Generality)

•

앞으로 필요할 것이라고 추측하여 미리 구현한 경우가 존재합니다.

interface PaymentMethod {
    fun processPayment(amount: Double)
}

class CreditCardPayment : PaymentMethod {
    override fun processPayment(amount: Double) {
        // ... code to process credit card payment ...
    }
}

class BitcoinPayment : PaymentMethod {
    override fun processPayment(amount: Double) {
        // ... code to process cash payment ...
    }
}
Kotlin
복사

16) 임시 필드 (Temporary Field)

•

특정 상황에서만 사용되는 변수가 존재합니다.

class Shopping {
    var eventDiscount: Double? = null

    fun getTotalPrice(items: List<Item>): Double {
        var total = items.sumOf { it.price }

        if (eventDiscount != null) {
            total -= total * eventDiscount!!
        }

        return total
    }
}
Kotlin
복사

개선

17) 메시지 체인 (Message Chain)

•

클라이언트가 하나의 객체에 다른 객체를 요청할 때, 그 객체가 다른 객체를 또 다시 요청하는 구조가 존재합니다.

class Order(val customer: Customer)
class Customer(val address: Address)
class Address(val city: City)
class City(val name: String)

// Client code
val order = Order(Customer(Address(City("New York"))))
val cityName = order.customer.address.city.name
Kotlin
복사

개선

18) 중개자 (Middle Man)

•

객체가 스스로의 책임을 다하지 못하고, 다른 객체로 책임을 위임합니다.

class Order(val totalCost: Double)

class PaymentProcessor {
    fun processPayment(order: Order, paymentMethod: PaymentMethod) {
        paymentMethod.pay(order.totalCost)
    }
}

interface PaymentMethod {
    fun pay(amount: Double)
}

class CreditCard : PaymentMethod {
    override fun pay(amount: Double) {
        // Implement payment logic here
    }
}


// Client code
val order = Order(100.0)
val paymentMethod = CreditCard()
PaymentProcessor.processPayment(order, paymentMethod)
Kotlin
복사

개선

19) 내부자 거래 (Insider Trading)

•

하나의 객체가 다른 객체의 내부와 지나치게 결합되어 있습니다.

class Trader(private val stockMarket: StockMarket) {

    fun buy(stock: Stock, quantity: Int): Double {
				// needs to know about the inner workings of StockMarket to make a trade.
        if (!stockMarket.stocks.contains(stock)) {
            throw RuntimeException("Stock not available in the market.")
        }
        val cost = stock.price * quantity
        stock.price += quantity // directly manipulates the price of Stock
        return cost
    }
}

class Stock(var price: Double) 

class StockMarket {
    var stocks: MutableList<Stock> = mutableListOf()

    fun addStock(stock: Stock) {
        stocks.add(stock)
    }
}
Kotlin
복사

개선

20) 거대한 클래스 (Large Classes)

•

한 클래스가 너무 많은 책임을 가지고 있습니다.

class Trader(var name: String, var address: String, var phoneNumber: String, var accountBalance: Double) {
    //...
    fun buy(stock: Stock, quantity: Int) {
        // buy logic
    }

    fun sell(stock: Stock, quantity: Int) {
        // sell logic
    }

    fun updateAddress(newAddress: String) {
        this.address = newAddress
    }

    fun updatePhoneNumber(newPhoneNumber: String) {
        this.phoneNumber = newPhoneNumber
    }

    fun deposit(amount: Double) {
        this.accountBalance += amount
    }

    fun withdraw(amount: Double) {
        if (this.accountBalance < amount) {
            throw IllegalArgumentException("Insufficient balance!")
        }
        this.accountBalance -= amount
    }
    //...
}
Kotlin
복사

개선

21) 서로 다른 인터페이스의 대안 클래스들 (Alternative Classes with Different Interfaces)

•

두 객체가 큰 틀에서 유사한 기능을 하지만 인터페이스가 다릅니다.

class StockTrader {
    fun purchaseStock(stock: Stock, quantity: Int) {
        // Buy logic...
    }

    fun sellStock(stock: Stock, quantity: Int) {
        // Sell logic...
    }
}

class CryptoTrader {
    fun acquireCrypto(crypto: Crypto, quantity: Int) {
        // Buy logic...
    }

    fun disposeCrypto(crypto: Crypto, quantity: Int) {
        // Sell logic...
    }
}
Kotlin
복사

개선

22) 데이터 클래스 (Data Class)

•

데이터 클래스에서 속성을 조작합니다.

// Data Class
data class Image(var width: Int, var height: Int, val format: String) {
    fun resize() {
        // ... code to resized width and height ...
    }
}
Kotlin
복사

23) 상속 포기 (Refused Bequest)

•

자식 객체에서 부모 객체의 메소드 중 일부를 사용하지 않습니다.

open class Vehicle {
    open fun startEngine() {
        // Start engine
    }

    open fun move() {
        // Move
    }

    open fun stop() {
        // Stop
    }
}

class Car: Vehicle() {
    override fun startEngine() {
        // Start car engine
    }

    override fun move() {
        // Car moves
    }

    override fun stop() {
        // Car stops
    }
}

class Bicycle: Vehicle() {
    override fun startEngine() {
        throw UnsupportedOperationException("Bicycles don't have engines")
    }

    override fun move() {
        // Bicycle moves
    }

    override fun stop() {
        // Bicycle stops
    }
}
Kotlin
복사

개선

24) 주석 (Comments)

•

코드 자체로 비지니스 로직을 충분히 설명할 수 없기 때문에 주석을 추가합니다.

class OrderProcessing {

    fun processOrder(order: Order) {
        // Validate order
        if (order.items.isEmpty()) {
            throw IllegalArgumentException("Order cannot be empty")
        }
        if (order.customer == null) {
            throw IllegalArgumentException("Customer information is required")
        }

        // Calculate total
        var total = 0.0
        for (item in order.items) {
            total += item.price
        }

        // Apply discount
        if (order.customer.isPremium) {
            total *= 0.9  // 10% discount for premium customers
        }

        // Create invoice
        val invoice = Invoice(order.customer, total)

        // Send invoice
        sendInvoice(invoice)
    }

    private fun sendInvoice(invoice: Invoice) {
        // logic to send the invoice
    }
}
Kotlin
복사

개선

다. Basic Refactoring

1) 개요

graph TD
    stage1[단계 1: 함수 구성 및 이름 짓기]
    Function(함수 추출 또는 인라인)
    Variable(변수 추출 또는 인라인)
    ChangeFunctionDeclaration(함수 선언 변경)
    ChangeVariableName(변수 이름 변경)
    VariableEncapsulation(변수 캡슐화)
    CreateParameterObject(매개변수 객체 생성)

    stage2[단계 2: 함수 묶기]
    GroupFunctionsInClass(클래스로 함수 묶기)
    GroupFunctionsInTransformFunction(변환 함수로 함수 묶기)

    stage3[단계 3: 단계 쪼개기]
    
    stage1 --> Function -->  stage2
    stage1 --> Variable -->  stage2
    stage1 --> ChangeFunctionDeclaration --> stage2
    stage1 --> ChangeVariableName --> stage2
    stage1 --> VariableEncapsulation --> stage2
    stage1 --> CreateParameterObject --> stage2
    
    stage2 --> GroupFunctionsInClass --> stage3
    stage2 --> GroupFunctionsInTransformFunction --> stage3
Mermaid
복사

2) 함수 추출 또는 인라인

‘목적’과 ‘구현’의 분리를 기준으로 함수를 추출할 것

•

코드가 구현을 담고 있으면 함수로 추출합니다. 반대로 추출된 함수가 목적을 담고 있으면 인라인합니다. 

•

함수 이름이 함수 본문 보다 길다거나 함수 본문이 너무 짧다는 것은 중요하지 않습니다.

•

함수 추출 예시

class OrderProcessing() {

    fun placeOrder(order: Order) 
        val totalPrice = order.items.sumOf { item -> item.price }
        var finalPrice = if (order.items.size >= 10) totalPrice * 0.9 else totalPrice
        order.status = Status.COMPLETED
        order.totalPrice = finalPrice
    }
}
Kotlin
복사

class OrderService() {
	fun placeOrder(order: Order) {
        val totalPrice = order.items.sumOf { item -> item.price }
        val finalPrice = applyDiscounts(totalPrice)
        finalizeOrder(finalPrice)
    }

    private fun applyDiscounts(totalPrice: Double): Double {
        return if (order.items.size >= 10) totalPrice * 0.9 else totalPrice
    }

    private fun finalizeOrder(finalPrice: Double) {
        order.status = Status.COMPLETED
        order.totalPrice = finalPrice
    }
}
Kotlin
복사

•

함수 인라인 예시

class OrderService() {
	fun placeOrder(order: Order) {
        val totalPrice = calculateTotal()
        val finalPrice = applyDiscounts(totalPrice)
        finalizeOrder(finalPrice)
    }
	// ...생략
}
Kotlin
복사

class OrderService() {
	fun placeOrder(order: Order) {
        val totalPrice = order.items.sumOf { item -> item.price }
        val finalPrice = applyDiscounts(totalPrice)
        finalizeOrder(finalPrice)
    }
	// ...생략
}
Kotlin
복사

3) 변수 추출 또는 인라인

함수와 마찬가지로 ‘목적’과 ‘구현’을 기준으로 변수를 추출할 것

•

만약 추출 대상 코드가 함수 외부에도 의미를 갖는다면 변수가 아니라 함수로 추출해야 합니다.

•

변수 추출 예시

private fun applyDiscounts(totalPrice: Double): Double {
    return if (order.items.size >= 10) totalPrice * 0.9 else totalPrice
}
Kotlin
복사

private fun applyDiscounts(totalPrice: Double): Double {
		val isDiscountApplicable = order.items.size >= 10
		val discountRate = 0.9
    return if (isDiscountApplicable) totalPrice * discountRate else totalPrice
}
Kotlin
복사

•

변수 인라인 예시

private fun applyDiscounts(totalPrice: Double): Double {
		val itemSize = order.items.size
		val discountRate = 0.9
    return if (itemSize >= 10) totalPrice * discountRate else totalPrice
}
Kotlin
복사

private fun applyDiscounts(totalPrice: Double): Double {
		val discountRate = 0.9
    return if (order.items.size >= 10) totalPrice * discountRate else totalPrice
}
Kotlin
복사

4) 함수 선언 변경

함수의 이름과 매개변수를 ‘목적’에 맞게 선언할 것

•

함수 이름의 경우, 함수 내부의 구현이 아니라 함수가 호출되는 곳에서 사용되는 목적에 맞게 정의해야 합니다.

•

매개변수의 경우, 필수 값만을 전달하여 활용도를 높일 지 또는 연관 객체를 전달하여 캡슐화 수준을 높일 지를 결정해야 합니다. 

•

함수 이름 변경 예시

class Bank() {
    fun calculateInterestByAccountType(account: Account): Double {
        val rate = if (account.type == AccountType.CHECKING) 0.01 else 0.02
        return account.balance * rate
    }
}
Kotlin
복사

class Bank() {
    fun calculateInterest(account: Account): Double {
        val rate = if (account.type == AccountType.CHECKING) 0.01 else 0.02
        return account.balance * rate
    }
}
Kotlin
복사

•

매개변수 변경 예시

fun applyDiscount(totalPrice: Double, numberOfItems: Int): Double {
		val discountRate = 0.9
    return if (numberOfItems >= 10) totalPrice * discountRate else totalPrice
}
Kotlin
복사

fun applyDiscount(order: Order): Double {
		val discountRate = 0.9
    return if (order.items.size >= 10) order.totalPrice * discountRate else order.totalPrice
}
Kotlin
복사

5) 변수 캡슐화

데이터의 유효범위가 넓은 가변 데이터는 접근과 갱신에 대해 캡슐화할 것

•

유연한 프로그래밍 환경에서는 코드 전반에 걸쳐 유효범위가 넓은 가변 데이터가 존재할 가능성이 높습니다.

•

OOP 환경에서는 클래스를 벗어난 가변 데이터 자체가 용인되지 않습니다.

6) 변수 이름 변경

맥락 안에서 변수의 ‘목적’을 명확하게 이해할 수 있게 명명할 것

•

맥락 안에서 이해할 수 있다면 변수명을 한 글자로 짓는 것도 괜찮습니다.

•

DB에 저장되는 영속성 데이터의 경우, 변수명에 더 신경써야 합니다.

7) 매개변수 객체 생성

관계 있는 데이터 뭉치가 보이면 객체로 묶을 것

•

데이터 뭉치를 객체 기반으로 구조화하는 과정이 반복되면, 문제를 보다 쉽게 해결할 수 있는 길이 보입니다.

8) 여러 함수를 클래스로 묶기

공통 데이터 중심의 함수 뭉치가 보이면 클래스로 묶을 것

9) 여러 함수를 변환 함수로 묶기

팀의 스타일이 ‘변환 함수로 묶기’일 경우만 채택, 아니라면 클래스로 묶을 것

1st Edition

가. Basic Refactoring

1. 메소드를 나누는 이유

•

긴 메소드에는 복잡한 로직과 많은 정보가 엉키기 쉽기 때문에 문제

•

다른 메소드에서 사용할 가능성이 높아짐

•

오버라이딩이 쉬워짐

2. Precondition of Extracting Method

•

특정 코드를 새로운 메소드로 나누기 전, 추출하려는 코드의 집합에 대한 유의미한 이름이 떠오르지 않는다면 추출하지 말 것

3. No Local Varialbes

•

추출하려는 코드 내에 사용되는 지역변수가 없다면 그냥 복사 붙여넣기하여 새로운 메소드를 생성

4. Using Local Variables

•

추출하려는 코드 내에 사용되는 지역변수가 있다면 새로운 메소드에 매개변수로 전달함

5. Reassigning a Local Variable

•

추출하려는 코드 내에 사용되는 변수가 새로운 메소드로 분류한 코드 외에서도 사용된다면 반환값으로 지정함. 

•

새로운 메소드로 분류한 코드 내에서만 사용된다면 새로 생성한 메소드의 지역변수로 사용함

// Before
void printOwing() {
	 Enumeration e = _orders.elements();
	 double outstanding = 0.0;
	 printBanner();
	 // calculate outstanding
	 while (e.hasMoreElements()) {
		 Order each = (Order) e.nextElement();
		 outstanding += each.getAmount();
		}
	 printDetails(outstanding);
 }

// After
void printOwing(double previousAmount) {
	 printBanner();
	 double outstanding = getOutstanding(previousAmount * 1.2);
	 printDetails(outstanding);
 }

 double getOutstanding(double initialValue) {
	 double result = initialValue;
	 Enumeration e = _orders.elements();

	 while (e.hasMoreElements()) {
		 Order each = (Order) e.nextElement();
		 result += each.getAmount();
	 }
	 return result;
 }
Java
복사

6. Inline Method & Temp

•

간단하게 표현할 수 있는 메소드를 굳이 나누는 것은 코드를 복잡하게 함

→ 코드해석에 어려움이 없다면 inline으로 코드를 간단

int getRating() {
	return (moreThanFiveLateDeliveries()) ? 2 : 1;
}

boolean moreThanFiveLateDeliveries() {
	return _numberOfLateDeliveries > 5;
}

// After
int getRating() {
	return (_numberOfLateDeliveries > 5) ? 2 : 1;
}
Java
복사

•

 의미가 간단한 경우면서 동시에 한번만 사용되는 변수의 경우, 변수를 제거하고 메소드로 대체함

double basePrice = anOrder.basePrice();
return (basePrice > 1000)

// After
return (anOrder.basePrice() > 1000)
Java
복사

7. Replace Temp with Query

•

메소드 이름만으로 맥락을 알 수 있을 만큼 간단한 식을 변수로 할당했다면, 이를 메소드로 변환하여 사용

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

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

double basePrice() {
	return _quantity * _itemPrice;
}
Java
복사

8. Introduce Explaining Variable

•

특정 식에 대한 의미가 한 눈에 들어오지 않는다면 변수를 선언하는 방식으로 의미를 명확히 할 것

if ( (platform.toUpperCase().indexOf("MAC") > -1) &&
		(browser.toUpperCase().indexOf("IE") > -1) &&
		wasInitialized() && resize > 0 )
	{
		// do something
	}

// After
final boolean isMacOs = platform.toUpperCase().indexOf("MAC") >-1;
final boolean isIEBrowser = browser.toUpperCase().indexOf("IE") >-1;
final boolean wasResized = resize > 0;
if (isMacOs && isIEBrowser && wasInitialized() && wasResized) {
	// do something
}
Java
복사

9. Split Temporary Variable

•

임시적으로 사용되는 변수일지라도 같은 이름의 변수를 사용하지 말것

→ 코드를 읽는 사람에게 혼동을 줄 수 있음

•

순환문의 인덱스와 Collecting temporary는 예외

double temp = 2 * (_height + _width);
System.out.println (temp);
temp = _height * _width;
System.out.println (temp);

// After
final double perimeter = 2 * (_height + _width);
System.out.println (perimeter);
final double area = _height * _width;
System.out.println (area);
Java
복사

10. Remove Assignments to Parameters

•

메소드의 매개변수로 전달된 값을 조작하지 말 것

→ 자바에선는 pass by value의 원칙이 적용되기 때문에 discount 메소드 외부에서 inputVal의 값이 변경되지 않지만, 다른 언어(pass by reference)를 사용하는 reader에게 혼란을 줄 수 있음

→ 일관적인 사용성을 감안하면 매개변수에 변화를 주지 않는 것이 코드를 더욱 명확하게 만들어 줌

int discount (int inputVal, int quantity, int yearToDate) {
		if (inputVal > 50) inputVal -= 2;

// After
int discount (int inputVal, int quantity, int yearToDate) {
		int result = inputVal;
		if (inputVal > 50) result -= 2;
Java
복사

11. Replace Method with Method Object

•

지역변수가 너무 많아서 메소드 분할이 어려울 경우, 메소드 객체로 대체한다

class Order...
	double price() {
		double primaryBasePrice;
		double secondaryBasePrice;
		double tertiaryBasePrice;
		// long computation;
		...
	}

// After
class Order...
	double price(){
		return new PriceCalculator(this).compute()
	}
}

class PriceCalculator...
compute(){
	double primaryBasePrice;
	double secondaryBasePrice;
	double tertiaryBasePrice;
	// long computation;
	return ...
}
Java
복사

Class Account
		int gamma (int inputVal, int quantity, int yearToDate) {
			int importantValue1 = (inputVal * quantity) + delta();
			int importantValue2 = (inputVal * yearToDate) + 100;
			if ((yearToDate - importantValue1) > 100)
			importantValue2 -= 20;
			int importantValue3 = importantValue2 * 7;
			// and so on.
			return importantValue3 - 2 * importantValue1;
		}
	}

// After
class Gamma...
		private final Account _account;
		private int inputVal;
		private int quantity;
		private int yearToDate;
		private int importantValue1;
		private int importantValue2;
		private int importantValue3;

		Gamma (Account source, int inputValArg, int quantityArg, int yearToDateArg) {
			_account = source;
			inputVal = inputValArg;
			quantity = quantityArg;
			yearToDate = yearToDateArg;
		}

		int compute () {
			importantValue1 = (inputVal * quantity) + _account.delta();
			importantValue2 = (inputVal * yearToDate) + 100;
			if ((yearToDate - importantValue1) > 100)
			importantValue2 -= 20;
			int importantValue3 = importantValue2 * 7;
			// and so on.
			return importantValue3 - 2 * importantValue1;
		}

		int gamma (int inputVal, int quantity, int yearToDate) {
			return new Gamma(this, inputVal, quantity,yearToDate).compute();
		}
Java
복사

나. Moving features between elements

1. Move method / field

•

메소드나 필드나 많이 사용되는 class에 정의할 것

2. Extract Class

•

하나의 클래스에 너무 많은 기능이 있다면 연관성을 기준으로 두 개 이상의 클래스로 나눌 것

→ 시스템은 시간이 갈 수록 더욱 복잡해짐. 클래스도 더욱 복잡해지기 때문에 나눌 수 있는 클래스는 미리 나누는 것이 효율적

class Person {
	name,
	officeAreaCode,
	officeNumber,
	getTelephoneNumber()
}

// After
class Person {
	name,
	getTelephoneNumber()
}

class TelephoneNumber {
	areaCode,
	number,
	getTelephoneNumber()
}
Java
복사

3. Inline Class

•

리팩터링을 제대로 하면 각각의 클래스들이 너무 비는 경우가 발생하므로, 많이 사용되지 않거나 과하게 추출된 클래스는 관련 클래스에 포함시킴

4. Hide Delegate

5. Remove Middle Man

•

4, 5번은 추후 다시

6. Introduce Foreign Method

•

Server class에 메소드로 선언되지 않았지만 client class에 필요한 메소드가 있다면 아래와 같은 방식으로 Foreign Method 선언하여 사용 가능

Date newStart = new Date(previousEnd.getYear(),previousEnd.getMonth(),previousEnd.getDate()+1);

// After
Date newStart = nextDay(previousEnd);

private static Date nextDay(Date date){
	return new Date(date.getYear(),date.getMonth(),date.getDate()+1);
}
Java
복사

7. Introduce Local Extension

•

추후 다시 학습

다. SIMPLIFYING CONDITIONAL EXPRESSIONS

1. Decompose Conditional

if (date.before (SUMMER_START) || date.after(SUMMER_END))
	charge = quantity * _winterRate + _winterServiceCharge;
else charge = quantity * _summerRate;

// After
if (notSummer(date))
	charge = winterCharge(quantity);
else charge = summerCharge (quantity);
Java
복사

2. Consolidate Conditional Expression

double disabilityAmount() {
	if (_seniority < 2) return 0;
	if (_monthsDisabled > 12) return 0;
	if (_isPartTime) return 0;

// after
double disabilityAmount() {
	if (isNotEligableForDisability()) return 0;
Java
복사

3. Consolidate Duplicate Conditional Fragments

if (isSpecialDeal()) {
	total = price * 0.95;
	send();
}
else {
	total = price * 0.98;
	send();
}

// after
if (isSpecialDeal()) {
	total = price * 0.95;
}
else {
	total = price * 0.98;
}
send();
Java
복사

4. Remove Control Flag

•

control flag 대신 break나 continue 사용을 권장

→ 조건문의 목적성을 보다 명확하게 하므로

void checkSecurity(String[] people) {
	boolean found = false;
		for (int i = 0; i < people.length; i++) {
			if (! found) {
				if (people[i].equals ("Don")){
					sendAlert();
					found = true;
				}
				if (people[i].equals ("John")){
					sendAlert();
					found = true;
				}
			}
	}
}

// after
void checkSecurity(String[] people) {
	for (int i = 0; i < people.length; i++) {
		if (people[i].equals ("Don")){
			sendAlert();
			break; // or return
		}
		if (people[i].equals ("John")){
			sendAlert();
			break; // or return
		}
	}
}
Java
복사

5. Replace Nested Conditional with Guard Clauses

double getPayAmount() {
	double result;
	if (_isDead) result = deadAmount();
	else {
		if (_isSeparated) result = separatedAmount();
		else {
			if (_isRetired) result = retiredAmount();
			else result = normalPayAmount();
		};
	}
	return result;
};

// after
double getPayAmount() {
	if (_isDead) return deadAmount();
	if (_isSeparated) return separatedAmount();
	if (_isRetired) return retiredAmount();
	return normalPayAmount();
};
Java
복사

라. 요약

리팩터링이란 코드의 결과는 동일하지만 내부의 구조를 개선하기 위해 소프트웨어를 수정하는 것이다. 리팩터링의 목적은 코드 작성 후에 체계적으로 설계된 코드로 바꾸는 것이다.

1) 예제 이해

•

Movie class: 단순한 데이터 클래스

•

Rental class: 고객이 영화를 빌리는 행위을 표현

•

Customer class: 상점에 방문한 고객을 표현하며 고객의 데이터 엑세서(다른 클래스 접근함수)를 포함함

2) 리팩터링 전 테스트 코드 작성

•

Refactoring 시작 전, 반드시 일련의 테스트 코드를 작성해야 함

•

테스트 코드는 self-checking 기능을 포함하여 추후 테스트 작업에 따른 시간을 최소화 해야 함 

: self-chcking 기능이란 다음의 기능을 포함함. 모든 테스트 통과 시, okay 등의 표시, 의도한 결과와 테스트 결과가 다를 시, 차이점 출력 등

3) 메소드 추출

•

더 작은 조각의 코드로 작성하는 것은 코드의 의미를 더욱 명확히 하여 협업 시 생산성이 증가함

•

Decomposing이란 작업 대상을 찾아서 기존 코드에서 추출하는 것이다. 논리적으로 뭉쳐진 코드 그룹이 1차 타겟이다. 주로 반복문이나 switch문 등의 큰 논리적 집합(logical clump)

•

Decomposing 할 때, 주의할 점으로 아래의 세 가지가 있다.

•

기존 코드에서 Decomposing하여 새로운 메소드로 분리 시, 분리된 메소드 내에서 값이 변경되는 변수와 변경되지 않는 변수에 나누어 관리해야 한다.  특히 값이 변경되는 변수는 주의가 필요함. 값이 변경되는 변수는 분리된 메소드에서 새로운 변수로 생성하여 메소드의 반환값으로 사용

다. 값이 변경되지 않을 경우, 매개변수로 받아서 사용

•

반드시 테스트하여 이상유무 확인할 것(인간적 실수 걸러내기)

•

새롭게 생성한 메소드에 맞게 변수명을 변경할 것

4) 메소드 이전

•

일반적으로 메소드는 같은 데이터를 공유하는 객체 내 존재하는 것이 깔끔함

: 같은 데이터를 공유하는 클래스 내 메소드가 생성되면 같은 데이터에 대해 매개변수로 전달 받지 않아도 됨. 변수 사용을 최소화할 수 있음.

•

new method를 생성하고 old method를 바로 제거하기 보다 old method가 사용된 software interface 내에서 new method를 테스트해야 한다.

•

테스트한 후 이상 없을 시, 기존 메소드(amountFor)가 사용된 코드에서 이를 제거하고 new method로 바꿈

•

일시적으로 사용하는 변수를 최소화하여 사용해야 함

: 일시적으로 사용하는 변수가 이곳저곳에서 많이 사용되면 각각의 변수의 사용처를 놓칠 수 있으므로 나중에 큰 문제로 이어질 수 있음

: 이러한 임시변수는 길게 작성된 메소드에 많이 있음

: 변수를 사용하지 않고 메소드 호출을 두 번 이상 하는 것은 계산을 중복 실행하는 것이므로 성능에 영향을 줄 수 있음. 이 문제에 대해 'Refactoring and Performance' 부분에서 다룸

// Old method
class Customer...
	 private double amountFor(Rental aRental) {
	 double result = 0;
	 switch (aRental.getMovie().getPriceCode()) {
		 case Movie.REGULAR:
		 result += 2;
		 if (aRental.getDaysRented() > 2)
		 result += (aRental.getDaysRented() - 2) * 1.5;
		 break;
		 case Movie.NEW_RELEASE:
		 result += aRental.getDaysRented() * 3;
		 break;
		 case Movie.CHILDRENS:
		 result += 1.5;
		 if (aRental.getDaysRented() > 3)
		 result += (aRental.getDaysRented() - 3) * 1.5;
		 break;
	 }
 return result;
 }
Java
복사

// New method
class Customer...
private double amountFor(Rental aRental) {
		return aRental.getCharge();
}

class Rental...
double getCharge() {
		double result = 0;
		switch (getMovie().getPriceCode()) {
		case Movie.REGULAR:
			result += 2;
			if (getDaysRented() > 2)
				result += (getDaysRented() - 2) * 1.5;
			break;
		case Movie.NEW_RELEASE:
			result += getDaysRented() * 3;
			break;
		case Movie.CHILDRENS:
			result += 1.5;
			if (getDaysRented() > 3)
				result += (getDaysRented() - 3) * 1.5;
			break;
		}
		return result;
	}

Java
복사

5) 메소드 추출

•

frequentRenterPoints를 계산하는 로직을 분리할 수 있습니다.

•

frequentRenterPoints 계산 시 사용하는 모든 메소드가 Rental class에 있으므로 객체를 이동하여 메소드 생성합니다.

•

frequentRenterPoints의 선언부가 while 반복문 위쪽에 존재함으로,  새로운 메소드 내부에는 frequentRenterPoints 변수에 접근하는 로직을 사용할 수 없음

// Old method
class Customer...
		int frequentRenterPoints = 0;
		while (rentals.hasMoreElements()) {
			Rental each = (Rental) rentals.nextElement();

			// add frequent renter points
			frequentRenterPoints++;
			// add bonus for a two day new release rental
			if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE) && each.getDaysRented() > 1)
				frequentRenterPoints++;
			// show figures for this rental
			result += "\t" + each.getMovie().getTitle() + "\t" + String.valueOf(each.getCharge()) + "\n";
			totalAmount += each.getCharge();
		}
Java
복사

// New method
class Rental...
int getFrequentRenterPoints() {
	if ((getMovie().getPriceCode() == Movie.NEW_RELEASE) && getDaysRented() > 1)
		return 2;
	else
		return 1;
}

class Customer...
		int frequentRenterPoints = 0;
		while (rentals.hasMoreElements()) {
			Rental each = (Rental) rentals.nextElement();

			// add frequent renter points
			frequentRenterPoints += each.getFrequentRenterPoints();

			// show figures for this rental
			result += "\t" + each.getMovie().getTitle() + "\t" + String.valueOf(each.getCharge()) + "\n";
			totalAmount += each.getCharge();
		}
Java
복사

6) 임시변수 제거

•

frequentRenterPoints와 totalAmount 변수를 제거하고 새로운 메소드를 생성합니다.

•

일시적인 변수를 제거함으로써 기존 메소드의 재활용성이 향상됩니다.

private double getTotalCharge() {
		double result = 0;
		Enumeration<Rental> rentals = _rentals.elements();
		while (rentals.hasMoreElements()) {
			Rental each = (Rental) rentals.nextElement();
			result += each.getCharge();
		}
		return result;
	}

	private int getTotalFrequentRenterPoints() {
		int result = 0;
		Enumeration<Rental> rentals = _rentals.elements();
		while (rentals.hasMoreElements()) {
			Rental each = (Rental) rentals.nextElement();
			result += each.getFrequentRenterPoints();
		}
		return result;
	}

public String statement() {
		Enumeration<Rental> rentals = _rentals.elements();
		String result = "Rental Record for " + getName() + "\n";

		while (rentals.hasMoreElements()) {
			Rental each = (Rental) rentals.nextElement();

			// show figures for this rental
			result += "\t" + each.getMovie().getTitle() + "\t" + String.valueOf(each.getCharge()) + "\n";
		}

		// add footer lines
		result += "Amount owed is " + String.valueOf(getTotalCharge()) + "\n";
		result += "You earned " + String.valueOf(getTotalFrequentRenterPoints()) + " frequent renter points";
		return result;
	}
Java
복사

7) 분기문을 다형성 기반의 객체로 이전

•

조건문 내에서 사용되는 데이터의 경우, 일반적으로 같은 객체 내 데이터를 사용합니다.

: 같은 객체 내 데이터와 메소드가 공존하면, 데이터에 수정사항 발생 시 해당 메소드에 쉽게 반영할 수 있습니다.

: getCharge 메소드의 경우 Movie 클래스 내 데이터를 주로 다루므로, Movie 클래스로 이동하는 것이 좋습니다.

: 메소드의 매개변수를 선택할 때, 변동 가능성이 적은 데이터를 선택하여 추후 수정 시 편리할 수 있도록 합니다. Type information의 경우 변동성이 크므로, 메소드 내 데이터로 남기는 것이 향후 관리면에서 효율적입니다.

// Old Methods
Class Rental...
double getCharge() {
 return _movie.getCharge(_daysRented);
}
int getFrequentRenterPoints() {
 return _movie.getFrequentRenterPoints(_daysRented);
 }
class movie...
Java
복사

// New Methods
class Movie...
 double getCharge(int daysRented) {
	 double result = 0;
	 switch (getPriceCode()) {
		 case Movie.REGULAR:
		 result += 2;
		 if (daysRented > 2)
		 result += (daysRented - 2) * 1.5;
		 break;
		 case Movie.NEW_RELEASE:
		 result += daysRented * 3;
		 break;
		 case Movie.CHILDRENS:
		 result += 1.5;
		 if (daysRented > 3)
		 result += (daysRented - 3) * 1.5;
		 break;
		}
	 return result;
 }

int getFrequentRenterPoints(int daysRented) {
	 if ((getPriceCode() == Movie.NEW_RELEASE) && daysRented > 1)
	 return 2;
	 else
	 return 1;
 }
Java
복사

•

메소드 이동 시, 기존 메소드를 완전히 삭제하지 않음으로써 타입 및 인터페이스 환경을 유지합니다.

: 같은 객체 내 데이터와 메소드가 공존하면, 데이터에 수정사항 발생 시 해당 메소드에 쉽게 반영 가능

: getCharge method의 경우 Movie class 내 데이터를 주로 다루므로 Movie class로 이동하는 것이 좋음

: 메소드의 매개변수를 선택할 때, 변동 가능성이 적은 데이터를 선택하여 추후 수정 시 편리할 수 있도록 함. Type information의 경우 변동성이 크므로, 메소드 내 데이터로 남기는 것이 향후 관리면에서 효율적

8) 상속 구조 기반의 클래스 세분화

•

switch문을 분할하는 방법은 각 Movie type에 대해 Movie를 상속 받는 하위 클래스로 세분화하는 것입니다.

•

하지만 문제점은 Movie 클래스의 price 관련 메소드들을 모든 하위 클래스와 부모 클래스(Movie)가 각자 관리하다보면 추후 유지보수에 큰 어려움을 겪을 수 있다는 점입니다.

: price와 관련된 class를 추가 생성하여 Movie 관련 클래스들이 price class의 메소드를 사용하도록 함

•

switch문에 대해 Movie의 자식 클래스로 변환하는 과정은 아래 세 단계를 거칩니다.

1단계: Replace Type Code with State/Strategy

→ Price class를 abstract class로 생성 및 이하 priceCode별 자식 class 생성

→ 모든 자식 클래스에 getPriceCode 메소드 생성

→ Movie와 Price class 간 접점 메소드 생성(setPriceCode)

2단계: Move Method

→ getCharge 메소드를 Movie 클래스에서 Price 클래스로 이동

3단계: Replace Conditional with Polymorphism

→ getCharge, getFrequentRenterPoints 두 메소드에 대해 다형성을 활용하여 Price class 내 자식 클래스의 하위 메소드로 분리

9) 리팩터링 결과 비교

•

첫번째 다이어그램과 비교해보면 상당부분에서 차이 확인

•

example code 바로가기(https://github.com/MJbae/Refactoring_JAVA/tree/chapter1_refactoring)

•

Before

•

After