TDD, 클린 코드 with Kotlin 6기 블랙잭 피드백

Step2

https://github.com/next-step/kotlin-blackjack/pull/528

Test Double

단위 테스트를 위해 의존성 주입 부분에 테스트 더블을 사용해 테스트를 좀 더 편리하게 할 수 있도록 구현하였다. 다만, 피드백을 받으며 Stub, Mock, Fake 등 테스트 더블의 종류에 대해 명확히 알고 사용하는게 좋을 것 같아 정리해보려 한다.

• Dummy
  • 동작하지 않아도 테스트에는 영향을 미치지 않는 객체를 Dummy 객체라고 한다.
  • 단순 인스턴스화한 객체를 의미한다.
• Stub
  • 테스트에서 호출된 요청에 대해 미리 준비해둔 결과를 제공한다.
  • 즉, 테스트를 위해 미리 만들어놓은 객체만을 반환한다. (객체의 상태를 검증할 때 주로 사용한다.)
• Mock
  • 호출에 대한 기대를 명세하고 내용에 따라 동작하도록 프로그래밍 된 객체이다.
  • 실제로 함수가 잘 호출되었는지 검증하는데 더 목적이 있고(행동 검증) 테스트 속도 개선 및 검증하고 싶은 테스트에 집중하고 싶을 때 검증하고자 하는 것을 제외한 다른 객체들을 모킹하여 사용한다.
• Fake
  • 복잡한 로직을 가진 함수의 동작을 단순화하여 구현한 객체이다.
  • 즉, 동작은 하지만 실제 사용되는 객체처럼 정교하게 동작하지는 않는 객체를 말한다.
  • 예를 들면, InMemoryRepository와 같이 테스트를 위해 가짜 데이터베이스를 만드는 것과 같은 예시가 있다. 정교하지는 않지만 실제 데이터베이스와 동일한 역할을 한다.

참고

https://tecoble.techcourse.co.kr/post/2020-09-19-what-is-test-double/

Lazy Property 사용

불변 객체라면 접근할 때마다 로직을 실행하지 않고 처음 접근했을 때 한번만 실행하고 초기화하는 방법을 사용할 수 있다.

이렇게 사용할 경우 중복되는 계산을 피해 메모리 절약을 할 수 있다.

val lazyValue: String by lazy {
    println("computed!") // 처음 접근할 때 딱 한번만 실행
    "Hello"
}

//  println(lazyValue)
//  println(lazyValue)
//  -- 출력 -- 
computed!
Hello
Hello

참고

https://kotlinlang.org/docs/delegated-properties.html#lazy-properties

빌더와 조정자

메서드 네이밍에 대한 리뷰를 받았다. 사실 메서드명은 최대한 가독성있게 작성하려고 노력했지만 반환 타입에 대해서는 신중하게 생각하지 않았던 것 같다.

엘레강트 오브젝트 책 내용 중 좋은 메서드 네이밍을 하는 방법이 제시되어 있다.

빌더와 조정자 에 대한 내용이었는데

• 빌더
  • 빌더는 뭔가를 만들고 새로운 객체를 반환하는 메서드를 말한다. 반환 타입은 절대 void가 될 수 없으며 명사, 형용사로 표현한다.

fun pow(base: Int, power: Int): Int
fun employee(id: Int): Employee
fun parsedCell(x: Int, y: Int): String
fun bytedSaved(content: String): Int

• 조정자
  • 조정자는 객체로 추상화한 엔티티를 수정하는 메서드를 말한다. 반환 타입은 항상 void이며 이름은 항상 동사이다. 
  • 조정자의 경우 의미를 좀 더 풍부하게 설명하기 위해서 부사 활용이 가능하다.

fun save(content: String)
fun put(key: String, value: Float)
fun remote(emp: Employee)
fun quicklyPrint(id: Int)

 

- 객체지향적인 접근법으로 메서드명을 잘 지으려면 어떤 것을 반환하는 메서드 이름을 동사로 짓기 보다는 명사로 짓고(빌더) 무언가를 변경할 때에는 동사(조정자)를 사용하자
- 메서드 명을 작명하기 어렵다면 그 메서드에서 목표하는 작업이 하나가 아닐 가능성이 높다.
- Boolean 값을 반환하는 빌더는 예외. 이 경우엔 형용사

참고

https://lovethefeel.tistory.com/163?category=1002227

https://jessyt.tistory.com/141

Functional Interface

추상 메서드가 하나만 있는 인터페이스에 대해 functional interface 를 적용할 수 있다.

fun interface CardGenerator {
    fun generate(): Card
}

val randomCardGenerator = CardGenerator {
    Card(Rank.random(), Suit.random())
}

위와 같이 functional interface 를 적용하면 간결한 함수형 코드 작성이 가능해지며 짧은 람다 표현식으로 불필요한 코드를 줄일 수 있다.

참고

• https://kotlinlang.org/docs/fun-interfaces.html

Step3

https://github.com/next-step/kotlin-blackjack/pull/554

일급 컬렉션과 불변 객체

일급 컬렉션을 만들었다고 해서 반드시 내부가 불변 객체일 필요는 없다. 하지만 하나의 프로퍼티를 가지기 때문에 불변객체로 만들었을 때의 장점이 뚜렷해 아래와 같이 불변 객체로 함께 가져가는 것이 좋다.

data class Cards(
    val values: List<Card> = emptyList()
) {
    constructor(vararg card: Card) : this(values = card.toList())

    val sumOfScoreWithAceAsOne: Int by lazy {
        values.sumOf { it.getScore() }
    }

    val numberOfAce: Int by lazy {
        values.count { it.rank == Rank.ACE }
    }
}

리뷰어님은 불변객체로 만드는 것 자체는 좋은 시도이지만 현실 세계의 관점에서 보았을 때 플레이어나 딜러가 들고 있는 카드 더미 또한 변할 수 있어 무리하게 불변으로 만들 필요는 없어보인다는 의견을 말씀해주셨다.

현실에서 플레이어나 딜러가 들고 있는 카드 더미가 변할 수 있는 요구사항이기 때문에 무리하게 불변으로 만들지는 않아도 될 것 같다는 의견에 공감했고 불변객체를 우선적으로 생각하되, 유연하게 가변객체의 관점에서 생각해보는 것도 좋을 것 같다.

Step4

https://github.com/next-step/kotlin-blackjack/pull/568

컬렉션의 변경지점

class Cards(
    values: List<Card> = emptyList(),
) {
    var values: List<Card> = values
        private set

    constructor(vararg card: Card) : this(values = card.toMutableList())

    val sumOfScoreWithAceAsOne: Int
        get() = values.sumOf { it.getScore() }

    val numberOfAce: Int
        get() = values.count { it.rank == Rank.ACE }

    fun add(card: Card) {
        values = values + card
    }

    fun addAll(cards: List<Card>) {
        values = values + cards
    }
}

Cards 클래스를 가변하게 변경하면서 mutableList 를 만들고 방어적 복사로 반환할지, 또는 var (private set) 로 프로퍼티 자체를 변경 지점으로 두고 add를 할 때마다 새로운 리스트를 만들지 고민을 했다.

리뷰어님도 이 부분에 대해 리뷰를 해주셨고 values는 MutableList로 두고, 외부에 List를 반환하는 getter를 노출시킨 후에 접근할 때 values를 복제(copy)한 List를 만들어서 반환해도 좋을 것 같다는 의견을 주셨다.

var 를 통해 프로퍼티 자체를 변경 지점으로 두었을 때가 mutableList 로 리스트 내부에 변경지점을 두는 것보다 멀티 스레드 환경에서 안정성이 크기 때문에 프로퍼티 자체를 변경 지점으로 두는 방식을 선택했다.

다만 현재 미션에서 스레드 안정성을 고려해야할 상황은 아니기 때문에 속도가 더 빠른 mutableList를 사용하고 방어적 복사로 리턴하는 것도 좋은 방법인 것 같다.