[우아한테크코스 6기] 프리코스 2주차 자동차 경주 미션 후기

💡 2주차는 자동차 경주 미션입니다.

GitHub - woowacourse-precourse/java-racingcar-6

 

자동차 경주에 참가할 자동차들의 이름과 시도횟수를 입력받고, 시도 횟수 동안 0-9사이의 숫자 중 랜덤하게 숫자를 하나 뽑아 4이상이면 한 칸 앞으로 전진시켜 시도횟수까지 도달하면 가장 많이 전진한 자동차들의 이름을 출력하는 미션입니다.

 

이번 주차 미션에는 저번 1주차 과제에서 피드백 받은 내용들을 종합해 체크리스트를 만들어 미션을 진행했습니다.

---

💡 체크 리스트 

• [ ] 요구사항을 정확히 준수했는가?
• [ ] 커밋 메시지를 의미있게 작성했는가?
• [ ] git을 통해 관리할 자원에 대해서 고려했는가?
  • .class 파일은 java 코드가 있으면 생성할 수 있다. 따라서 굳이 git을 통해 관리하지 않아도 된다.
• [ ] Pull Request를 보내기 전 브랜치를 확인했는가?
• [ ] PR을 한 번 작성했다면 닫지 말고 추가 커밋을 한다.
• [ ] 네이밍에 신경을 썼는가?
• [ ] 축약으로 인해 의미가 퇴색되지 않았는가?
• [ ] 공백 코딩 컨벤션을 적용했는가?
  • if, for, while문 사이의 공백도 코딩 컨벤션이다.
• [ ] 문맥을 분리하는 부분에 공백을 적절히 사용했는가?
• [ ] 의미 없는 주석을 달지 않았는가?
• [ ] Java에서 제공하는 API를 적극 활용했는가?
• [ ] Collection을 적절하게 활용했는가? 배열을 쓴 부분은 없는지?
• [ ] README.md를 상세히 작성했는가?
• [ ] 기능 목록을 재검토했는가?
  • 기능 목록을 클래스 구현, 메서드 시그니처와 반환값과 같이 상세하게 적지 않는다. 언제든지 변경될 수 있기 때문이다.
• [ ] 기능 목록을 상시 업데이트 했는가?
  • 시작할 때 모든 기능 목록을 완벽하게 정리한다는 부담 보다는 문서를 계속 업데이트한다.
• [ ] 값을 하드 코딩하지는 않았는가?
• [ ] 클래스는 상수, 멤버변수, 생성자, 메서드 순으로 작성했는가?
• [ ] 변수 이름에 자료형이 있지는 않은가?
  • 변수 이름에 자료형은 사용하지 않는다. 
• [ ] 한 함수가 한 가지 기능만 담당하게 했는가?
• [ ] main( ) 함수도 길게 작성하지 않는다.
• [ ] 발생할 수 있는 예외 상황에 대해 고민했는가?
• [ ] 비즈니스 로직과 UI 로직을 분리했는가?
• [ ] 연관성이 있는 상수는 static final 대신 enum을 활용했는가?
  • 그렇지 않다면 enum을 활용하자.
• [ ] final 키워드를 사용해 값의 변경을 막았는가?
• [ ] 객체의 상태 접근을 제한했는가?
  • 인스턴스 변수의 접근 제어자는 private
• [ ] 객체는 객체스럽게 사용했는가?
• [ ] 필드(인스턴스 변수)의 수를 줄이기 위해 노력했는가?
  • 필드의 수가 많은 것은 객체의 복잡도를 높이고, 버그 발생 가능성을 높일 수 있다.
• [ ] 성공 케이스 뿐만 아니라 예외 케이스도 테스트했는가?

---

💡1주차 피드백

피드백 받은 내용 중 중요했던 피드백은 다음과 같습니다. 

 

1. View와 Model은 서로가 무엇을 하는 지 모르도록 독립적이어야 한다.

지난 미션에 실수한 부분이 있습니다. 바로 출력을 담당하는 OutputView에서 도메인을 그대로 파라미터로 받아서 출력했던 것인데요, 세세한 부분까지 신경썼다고 생각했는데 View에 대한 이해가 부족했던 것 같습니다. 

본론부터 말하자면 View와 Model은 서로가 어떤 역할을 하는 지 알 수 없도록 독립적으로 구성되어야 합니다.

 

그렇다면 만약 뷰를 통해 모델이 관한 정보를 출력해야 하는 상황이라면 어떻게 해야할까요?

컨트롤러에서 Model에 대한 데이터를 파싱하여 View에게 전달해주는 방식을 채택해야 합니다. 

 

즉, 컨트롤러에서는 Model의 정보를 그대로 넘겨주는 것이 아닌, Model의 정보를 풀어서 View에게 전달해주어야 합니다.

 

🚩 왜 그렇게 해야할까?

View에서 Model을 직접 사용하게 되면 크게 두 가지 위험요소가 있습니다.

 

1. Model의 변질 우려가 있다.

View는 출력에만 집중해야 합니다. 만약 View에서 모델을 직접 사용하게 되면, 모델에 직접 접근하여 값을 변동한다거나 삭제한다거나 하는 등 위험요인으로 작용할 수 있습니다. 

 

2. 결합도가 증가한다.

View가 Model에 직접 의존하면 두 구성 요소 간의 결합도가 증가하고, 이는 코드 유지 보수 및 확장을 어렵게 만들 수 있습니다. Model의 변경이 View에 영향을 미치면 View의 변경도 필요하게 되고, 이것은 유지 보수를 어렵게 만들 수 있습니다.

 

이러한 이유로 존재하는 것이 컨트롤러이기에, 이 컨트롤러의 역할을 잘 활용해야 합니다.

 

🚩 데이터를 어떻게 파싱할까?

Controller

Service

DTO

이 전 진행했던 프로젝트의 코드를 참고해보겠습니다. 해당 메소드는 회원의 프로필 정보를 조회합니다.

메소드를 살펴보면 Controller에서 memberService에서 수행한 메소드를 View로 리턴하는데요. 이 때 MemberProfileDto 타입에 데이터를 담아서 View로 리턴하는 것을 볼 수 있습니다.

 

이처럼 Data-Tranfer-Object(DTO)를 사용해서 계층간 데이터를 전달할 수 있습니다.

 

즉, View에서는 Member 모델에 직접 의존하여 출력하는 것이 아닌 DTO라는 데이터 전달 객체를 사용해 간접적으로 Member에 대한 정보를 출력하는 것입니다.

 

DTO를 사용하는 방법 외에도 Controller를 통해 Model에서 가져온 데이터를 View에서 출력할 때 출력할 정보(필드)가 많지 않다면 데이터를 직접 파싱하는 방법도 있습니다. 

// Controller
String name = item.getName();
String price = item.getPrice();
outputView.printResult(name, price);


// OutputView
public void printResult(String name, String price) {
	System.out.println(name + ":" + price);
}

OutputView 계층에서는 Model에 대한 정보는 아무것도 모른 채 Controller에서 받아온 정보를 출력하는 데 집중할 수 있겠죠. 

 

<요약>

• View는 출력에만 집중한다.
• Model은 자신이 할 수 있는 역할에만 집중한다.
• Controller는 (DTO를 사용하거나 Model을 파싱하여) Model과 View를 간접적으로 이어주는 데 집중한다.

---

2. InputView와 OutputView에 대해

OutputView는 이름만 봐도 알 수 있듯이 '출력'하는 계층입니다.

그렇다면 InputView라고 한다면 어떤 계층일까요? 바로 '입력'하는 계층입니다.

 

저는 1주차 미션에서는 이렇게 생각했습니다.

• Player가 입력하는 값은 Player 객체 안에서 수행해야 한다.
• View는 '입력'을 수행하지 않고 '출력'만 수행해야 한다.

로그인 화면

이 말이 틀렸다는 것은 미션이 끝나고야 바로 알아챌 수 있었습니다.

 

우리는 입력과 출력을 통해 웹을 이용하고 있습니다. 간단한 예시를 하나 들어보자면 생각나는 것이 로그인입니다. 로그인 창에 아이디와 비밀번호를 Input을 받고, 로그인 버튼을 누르면 그에 따른 OutputView를 받습니다. 그렇다면 입력도 'View'라고 볼 수 있겠죠. View를 통해 데이터를 받기만 하는 것이 아닌 값을 입력해 주기도 하니까요.

 

이 점을 크게 간과하고 있었습니다. 객체에 대한 값은 객체 안에서 관리해야 한다는 말이, 외부에서 객체를 만들면 안된다는 말은 아니니까요.

 

이렇게 저번 주차에서는 View에 관한 잘못된 이해로 놓치는 부분들이 있었는데, 이번 주차에서는 이 점들을 잘 생각하며 미션을 진행했습니다!

---

💡이번 미션에서 배운 점

🚩Value Object(=VO)와 record 

 "원시값을 포장하자." 객체지향 생활체조 3번 규칙입니다. 이 규칙을 잘못 이해하고 있었습니다.

'원시값, primitive'라고 한다면 int, long, double과 같은 타입만 원시 타입이라고 생각했는데, 규칙에서 말한 것은 그게 아니였습니다. 규칙에서 말하는 원시값은 Integer, Long, String을 포함한 모든 데이터 타입입니다.

 

즉, 도메인에서 Integer, String과 같이 데이터 타입의 필드를 가진다면 그 필드를 래핑하여 새로운 타입으로 정의해서 사용하여, 가독성과 명시성을 높이라는 것이었습니다. 

 

코드로 예시를 하나 들어보겠습니다.

 

수정 전

public class GameAnswer {

    private List<Integer> answer;
	...
}

 

수정 후

public class GameAnswer {

    private List<AnswerNumber> answerNumberList;
}

public class AnswerNumber {
    private Integer number;

    public Answer(Integer number){
        ...
    }

    public Integer getNumber(){
        return number;
    }
}

 

확실히 수정한 코드가 Integer가 무엇을 뜻하는지 바로 캐치할 수 있어서 가독성면에서 좋은 것 같습니다.

 

뿐만 아니라 값에 대한 검증을 GameAnswer에서 하지 않고 AnswerNumber 클래스 내에서 number에 대해 자체적으로 검증할 수 있어 , 역할과 책임분리 측면에서도 더 이점을 가져갈 수 있습니다. 따라서 이번 미션에서는 사용자가 입력하는 모든 값들과 모델에서 인스턴스 필드로 가지는 모든 변수들을 새로운 클래스로 래핑하여 진행하여 가독성과 역할분리의 이점을 가져오도록 노력했습니다. 자동차 경주 게임에서 사용자가 입력한 값은 중간에 변하지 않는 '불변 객체'인데요. 이 점을 고려해서 final 키워드를 사용하던 중 Java 17의 새로운 문법을 알게 되었습니다. 바로 'record' 입니다.

 

시도 횟수에 대한 래핑 클래스입니다. 사용자가 입력한 시도 횟수는 중간에 변하면 안되는 값이므로 필드에 final 키워드를 붙여주었는데요. final 키워드를 붙이니 클래스 이름에 노란 밑줄이 뜨길래 설명을 보아하니 'Convert to a record'라고 뜨는 걸 볼 수 있었습니다. 뭔지 궁금해서 클릭을 해보니 IDE가 제안해주는 문법으로 바뀌는 걸 볼 수 있었습니다.

 

레코드?? 처음 보는 키워드라 검색을 해보니 자바 14에 도입된 클래스를 정의하기 위한 새로운 형태의 데이터 타입이라고 합니다.

 

데이터를 간결하게 저장하고 접근하기 위한 목적으로 설계된 문법인데, 이러한 객체를 Value Object, VO 라고 하며 record를 적용할 경우, 불변성과 자동 생성자 및 접근자 메소드를 제공한다고 합니다. 뿐만 아니라 필드 값이 같으면 두 객체를 동일하다고 판단하는 equals(), hashCode(), toString() 메소드를 자동으로 생성하여 적용시켜준다고 하는데요. 무엇보다도 간결한 정의와 함께 값의 불변성까지 보장해주니 그야말로 데이터를 담기에 아주 좋은 기능인 것 같습니다. 

 

이처럼 자동차 경주 게임에서 사용자가 입력한 값에 대한 필드를 래핑하던 중 이 값들은 중간에 바뀌지 않는다는 점을 고려하여 필드에 final 키워드를 붙여 주었습니다. final 키워드를 붙이고 getter를 작성하니 클래스 이름에 노란 밑줄과 함께 IDE가 record라는 새로운 기능을 제안해주는 것을 볼 수 있었습니다. IDE가 자동 변환해주는 것을 확인해보았는데, 코드가 엄청 깔끔하게 변환되는 것을 볼 수 있었습니다. 이 계기로 record 키워드와 VO에 대해 공부할 수 있었습니다. record가 무엇보다도 간결한 정의와 함께 값의 불변성까지 보장해주니 그야말로 데이터를 담기에 아주 좋은 기능이라고 판단하였고, 이에 사용자가 입력한 자동차의 이름과 시도 횟수에 대한 값을 저장할 때 생성자를 통해 검증하여 역할을 분리할 수 있었습니다. 뿐만 아니라 DTO 계층에도 불변성을 주는 record를 적극적으로 활용하여 가독성을 향상시켜 코드를 개선할 수 있었습니다.

 

 

🚩 UnmodifiableList와 toList()

입력한 자동차 이름들을 리스트로 변환하여 일급컬렉션의 필드값으로 설정하는 과정에서 설정한 리스트를 외부에서 수정하지 못하게 막아야 했습니다. 이 과정에서 UnmodifiableList에 대해 배울 수 있었습니다. 우선 원본 필드가 수정되지 않도록 final 키워드를 붙여준 후, 생성자에서 할당하기 위해 새로 생성한 리스트에는 UnmodifiableList를 붙인 후 원본 필드에 할당하여 원본 필드와, 새로 생성한 리스트 모두 중간에 변할 수 있는 여지를 막아주었습니다. 그러던 도중 새로 생성한 리스트를 마지막에 UnmodifiableList를 붙여 할당하는 방법이 아닌 스트림을 통해 리스트를 생성할 때 toList()를 붙여주기만 하면 수정을 막아주는 리스트를 생성할 수 있다는 점까지 알게 되어 toList를 적용시켜 할당하는 객체와 할당받는 필드 모두 값이 변경되는 것을 막을 수 있었습니다!

 

 

🚩 Mock과 MockitoStatic

Mock

기존에 Mock이 가짜 객체를 만든다는 개념은 알고 있었지만, ‘언제, 왜 사용해야 하는지’에 대한 이해가 부족했었는데, 최근 테스트에 대해 공부하면서, Mock을 언제 하는지에 대해 배울 수 있었습니다. Mock은 의존성 관리와 속도 향상 측면에서 이점을 제공하기도 하지만, 무엇보다도 테스트 코드 작성에 있어서 객체의 동작을 직접 통제할 수 있는 이점이 컸습니다. 예를 들어, 메소드가 다른 객체에 의존하는 경우, Mock을 사용하여 해당 객체의 동작을 직접 제어할 수 있었습니다. 이렇게 해서 단위 테스트를 작성할 때 메소드가 의존하는 객체의 동작에 대해 고민할 필요가 없어 이로써 코드의 가독성을 향상시키고, 테스트 코드와 비즈니스 로직 사이의 경계를 명확하게 유지하여 역할을 잘 분리할 수 있었습니다.

 

MockitoStatic

0-9사이의 난수 생성은 정적 팩토리 메소드로 구현하였는데, 정적 팩토리 메소드에 대해서는 모의 객체를 생성하여 동작을 제어할 수 없다고 생각했습니다. 그래서 static을 제거하고 이 메소드를 사용하는 자동차 클래스가 난수 생성 클래스를 의존하게 함으로써, 테스트 코드에서 Mock을 이용해 모의 객체를 만들어 특정 난수 값을 리턴하는 방식으로 테스트를 진행했습니다. 하지만 util 패키지 구조와 더불어 의존성을 고려했을 때 난수 생성기는 분명 정적 팩토리 메소드로 관리되어야 했기 때문에 더 좋은 방법이 없을까 검색하던 중 MockitoStatic을 사용하면 정적 팩토리 메소드를 가지는 클래스도 모의 객체를 만들 수 있다는 점을 알게 되었고, 이 MockitoStatic을 테스트 코드에 적용하여 메인 코드에는 정적 팩토리 메소드를 유지함과 동시에 테스트까지 완벽히 수행할 수 있었습니다 😀

 

🚩@ParameterizedTest

지난 피어 리뷰를 해주셨던 한 분께서 @ParameterizedTest에 대해 공부해보라고 알려주셔서 이번 주차 미션에서는 이 부분을 공부하고 적용시켜보았습니다. 기존에는 given 절에 테스트할 입력값을 직접 할당해서 테스트를 수행했는데, 파라미터 값으로 테스트 함으로써, 하나의 테스트에 여러 값들을 테스트할 수 있었고 테스트 코드를 조금 더 깔끔하게 구현할 수 있었을 뿐만 아니라 이 도구를 사용하여 파라미터로 값을 여러개 주면서 테스트의 정확도를 높일 수 있었습니다.

 

🚩테스트 코드의 Reflection Util

테스트 코드에서는 특정 필드에 값을 할당해주어야 하지만 메인 코드에서 setter가 없는 경우 어떻게 값을 할당할 지에 대한 이슈가 있었습니다. 테스트 때문에 메인 코드를 수정하는 것은 빈대를 잡으려다 초가삼간을 태우는 격이었기에 많은 고민이 필요했습니다. 그러나 다행히 테스트 도구 중에 필드값에 직접 접근하여 값을 설정할 수 있는 도구가 있음을 알게 되었습니다. 이 도구를 사용하면 private으로 접근 제어자가 막혀 있고, setter도 없는 필드에 값을 임의로 할당할 수 있다는 것이 매우 흥미로웠습니다. 이 유틸의 사용법을 익히고 적용한 결과, 기능 자체에 대한 테스트에 집중할 수 있었고, 메인 코드를 수정하지 않고도 원하는 상황을 시뮬레이션하고 테스트할 수 있었습니다.

 

 

🚩그 외 배운 점들 

메인 코드

1. 상태가없는 클래스 private으로 관리하는 것이 좋다.
2. DTO는 도메인과 같은 타입의 데이터를 가지고 있어야 한다. 
3. 불필요한 라인을 제거하자.
4. 유틸성이 짙은 클래스는 정적 팩토리 메소드를 고려하자.
5. DTO에 불변성을 주자. record를 사용하던지 final 키워드를 사용하던지
6. Getter 사용 지양 (객체에서 해결할수 있는 일은 객체에서 해결하자)
7. 생성자에서 멤버변수를 자체적으로 만들기보단 외부에서 주입하는 방식을 고려하자.
8. 모든 원시값과 문자열을 포장하자.
9. 중복이 없는 리스트를 고려한다면 Set을 적극 이용하자.
10. toString을 이용하기보다 뷰에서 파라미터를 이용해 그리는 것에 집중하자.
11. 공백 라인을 잘 활용하자.
12. 코드의 중복을 제거하자. 테스트코드도 마찬가지이다.

 

테스트 코드

• 테스트 코드도 코드다.
• 테스트 코드도 리팩터링을 통해 개선해나가야 하고, 특히 반복적으로 하는 부분을 중복되지 않게 만들어야 한다.
• 테스트를 위한 코드는 구현 코드에서 분리되어야 한다. 
• 테스트를 위한 편의 메서드를 구현 코드에 구현하지 말자. 
  •  테스트를 위해 구현코드를 변경하면 안된다는 의미. 테스트 도구를 찾아보자.
• 단위 테스트하기 어려운 코드를 단위 테스트 해보자.
• 테스트하기 어려운 것을 클래스 내부가 아닌 외부로 분리하려는 시도를 해본다.
• private 함수를 테스트하고 싶다면, 클래스 분리를 고려해보자.
• 테스트하기 쉽게 구현하기 위해서는 해당 역할을 수행하는 다른 객체를 만들 타이밍이 아닐지 고민해 볼 수 있다. 너무 많은 역할을 하고 있는 함수나 객체를 어떻게 의미있는 단위로 분할할지 초점을 맞춰보자.
• 처음부터 큰 단위의 테스트를 만들지 않도록 하자.

---

💡고민했던 점들

 

🚩 DTO가 VO를 사용해도 될까?

 

DTO의 필드에 VO를 사용하게 되는 경우, View 계층에서는 DTO를 통해 VO 값을 출력을 한다고 하면, VO에 대한 정보를 알게 됩니다. 만약 VO 생성자에 “값에 대한 비즈니스 검증”까지 구현되어있다면 DTO는 VO를 의존하고 VO는 util까지 의존하게 되는데 그렇다면 DTO에서 VO를 사용하는 것이 비즈니스 로직과 UI의 분리가 잘 이루어 졌다고 할 수 있을까에 대한 생각이 많았습니다. 우선 DTO에서는 VO를 사용하지 않고 원시타입을 사용하여 출력에 집중하도록 구현했지만, VO도 원시타입을 포장한 값일 뿐인 클래스라는 점에 중점을 두면 사용해도 될 것 같다는 점 때문에 생성자에서 VO에서 검증로직을 분리해야 할 지에 대해 생각해보아야 할 것 같습니다.

 

🚩 util의 기준이 무엇인가?

현재에는 정적 팩토리 메소드를 사용하는 팩토리 클래스를 util 패키지로 분리하였습니다. 하지만 util이란 네이밍은 모호한 느낌을 많이 준다고 생각합니다. 정확히 ‘어떤’기능을 하는 클래스들의 집합인지 판단하기에는 많이 부족한 이름입니다. 그래서 util 패키지로 묶을 것이 아니라 차라리 패키지를 나누더라도 패키지 이름을 명시적으로 작성하는 것이 좋을 지 고민이었습니다. util의 기준이 무엇인지 공부해보아야 하겠습니다. 

 

🚩패키징

깔끔한 패키지를 설계하고 싶었습니다. 그 과정에서 DTO 패키지를 Controller로 넣을지, View에 넣을지, 아니면 바깥에 둘 지 고민이 많았습니다. Controller에서도 DTO를 쓰고 View에서도 DTO를 받아서 쓰기 때문에 어느 한 곳에 넣을까 하다가, 모호하면 바깥에 두는 게 최선이라 생각하여 우선 바깥에 두었는데, 어디에 두는 게 좋은 패키징인 것인지 궁금합니다. 패키징도 아직 많이 부족하다 느껴 패키지를 나누는 기준과 설계에 공부하고 더 고민해 보아야겠습니다.

 

🚩비즈니스 검증과 유효성 검증의 분리

사용자가 입력한 값에 대해 유효성을 검증하는 것과 비즈니스 로직에 의거한 검증을 분리하였습니다. 유효성과 비즈니스 검증, 이 두 가지의 검증을 한 클래스에서 수행하는 것이 좋을 지, 아니면 지금처럼 분리하여 관리하는 것이 좋을 지 고민입니다. 비즈니스 로직은 항상 변경될 수 있다는 점을 생각해서 유효성 검증 이후 생성자에서 비즈니스 검증을 수행하도록 하였는데 ‘검증’이라는 공통된 기능 아래 이렇게 분리하는 것이 좋은 로직일까요? ‘공통’에 집중할 것인지, UI/비즈니스 ‘분리’에 집중해야 할 지 고민이 많았습니다.

 

🚩네이밍

좋은 네이밍은 경험으로부터 나오는 것 같습니다. 현재에도 좋은 메소드명, 좋은 필드명, 좋은 클래스명을 짓기 위해 노력하고 있지만, 그럼에도 불구하고 정말 마땅한 네이밍이 떠오르지 않는다면, 설계가 잘못된 것이 아닌 지 의심도 해보고 네이밍에 대해 많이 공부하고 생각하고 고민해야 할 것 같습니다.

---

💡한 줄 소감

즐기면 시간이 잘간다고 하지만, 이 순간을 즐김과 동시에 오랜 시간을 몰입하니 마냥 짧지는 않았던 한 주였고 짧지 않았던 만큼 배웠던 점들도 많은 한 주였습니다. 3주차도 화이팅ㅇ

 

GitHub - Dongwoongkim/java-racingcar-6