[우테코] 프리코스 4주차 - 다리 건너기 회고록

https://www.woowahan.com/

배달의 민족 운영사인 우아한형제들에서 운영하는 개발자 양성 프로젝트, 우아한테크코스에 지원하게 되었다.

우아한테크코스 프리코스과정에  4주차의 내가 시간을 많이 투자한 부분과 느낀점, 부족한점을 작성하는 회고록이다.

 

🔎 3주차 피드백 정리

비즈니스 로직과 UI 로직을 분리한다.

해당 피드백은 내가 고민한 부분을 답변해주는것 같았다.

주어진 Lotto 라는 클래스를 그에 맞는 역할을 담당하도록 로직을 분리했다.

분리하는 기준을 정하는 것에 시간을 많이 투자하였지만 기준이 명확하지 않아 힘들었다.
-> 현재 객체의 상태를 보기 위한 로그 메시지 성격이 강하다면 toString()을 통해 구현한다. View에서 사용할 데이터라면 getter 메서드를 통해 데이터를 전달해야한다.

 

객체의 상태 접근을 제한한다.

 

객체는 객체스럽게 사용한다.

해당 피드백은 내가 저번 3주차 미션에서 겪은 과정을 답변해주고 있었다.

• 참고자료 (getter를 사용하는 대신 객체에 메시지를 보내자)

필드(인스턴스 변수)의 수를 줄이기 위해 노력한다.

필드(인스턴스 변수)의 수가 많은 것은 객체의 복잡도를 높이고, 버그 발생 가능성을 높일 수 있다. 필드에 중복이 있거나, 불필요한 필드가 없는지 확인해 필드의 수를 최소화해야한다.

 

단위 테스트하기 어려운 코드를 단위 테스트하기

올바른 로또 번호가 생성되는 것을 테스트를 하는것이 어려워 6개의 번호가 생성되는(size=6) 을 확인하는 테스트 밖에 진행하지 못했다.
하지만 테스트하기 어려운 것은 클래스 내부가 아닌 외부로 분리하는 시도를 거친다면 테스트를 할 수 있었다 !

• 참고자료 (메서드 시그니처를 수정하여 테스트하기 좋은 메서드로 만들기)

더 많은 피드백이 있었고, 이번 3주차 피드백은 정말 감탄하면서 본 것 같다.

 

📌 미션에 들어가기 전 목표

• 클래스(객체)를 분리하는 연습
• 리팩터링
• 주어진 요구사항을 꼼꼼히 읽기

🎪 다리 건너기 미션

[오징어게임 - 다리건너기 미션의 한 장면]

이번 미션은 세계에서도 엄청나게 유명해진 오징어게임의 다리건너기 미션중의 하나인 프로그램을 구현하게되어 너무 기대가 되었다. 주어진 요구사항과 출력문을 확인해보자 !

 

👀 추가된 요구 사항 정리

• 함수(또는 메서드)의 길이가 10라인을 넘어가지 않도록 구현한다.
• 메서드의 파라미터 개수는 최대 3개까지만 허용한다
• 아래 있는 InputView, OutputView, BridgeGame, BridgeMaker, BridgeRandomNumberGenerator 클래스의 요구사항을 참고하여 구현한다.
• 각 클래스의 제약 사항은 아래 클래스별 세부 설명을 참고한다.
  이외 필요한 클래스(또는 객체)와 메서드는 자유롭게 구현할 수 있다.
  • InputView 클래스에서만 camp.nextstep.edu.missionutils.Console 의 readLine() 메서드를 이용해 사용자의 입력을 받을 수 있다.
  • BridgeGame 클래스에서 InputView, OutputView 를 사용하지 않는다.

정말 어려운 요구 사항들로만 구성되어있었고 코드를 하나씩 내가세운 기준에 맞게 구현해보았다.
그리고 추가된 요구사항을 확인하며 리팩터링해가는 방식으로 구현했다.

✔  기능 구현 목록 작성

- [X] 다리의 길이를 입력받는다.
    - [X] 다리의 길이는 3부터 20 사이의 숫자여야한다.
    - [X] 다리의 입력 값은 숫자여야한다.
    - [X] 입력 값이 3과 20 사이의 숫자가 아닌경우 
    `IllegalStateException`를 발생시키고 "[ERROR]"로 시작하는 메시지 출력한다.

- [X] 입력한 길이만큼 0과 1 중 무작위 값으로 두 개의 다리를 생성한다.
    - [X] 다리의 시작은 `[`, 다리의 끝은 `]` 로 표시한다.
    - [X] 다리 칸의 구분은 `|`(앞뒤 공백 포함) 문자열로 구분한다.
    - [X] 무작위 값이 0인경우 아래칸이며 D값으로 정한다.
    - [X] 무작위 값이 1인경우 위칸이며 U값으로 정한다.

- [X] 플레이어는 입력한 길이만큼 라운드를 진행할 수 있다.
    - [X] 플레이어는 이동할 칸을 U(위 칸), D(아래 칸)으로 입력받는다.
        - [X] 생성된 다리가 이동할 수 있는 칸인 경우 O를 표시한다.
        - [X] 생성된 다리가 이동할 수 없는 칸인 경우 X를 표시한다.
            - [X] 게임을 다시 시도할지 여부를 입력할 수 있다.
                - [X] 재시도 (R) 입력 시, 이동할 칸을 처음부터 다시 입력받는다.
                - [X] 종료 : (Q) 입력 시, 최종 게임 결과로 이동하며 게임에 실패한다.
        - [X] 선택되지 않은 칸은 공백 한칸을 표시한다.
    - [X] 생성된 다리가 더 이상 없는 경우 최종 게임 결과로 이동하며 게임에 성공한다.
- [X] 최종 게임 결과를 출력한다.
    - [X] 플레이어가 이동한 칸 만큼 표시된 두 개의 다리를 보여준다.
- [X] 게임 성공 여부를 확인한다.
- [X] 총 시도한 횟수를 확인한다.

💻 기능 구현

MVC 모델 적용기

bridge
	controller
    	BridgeController (domain과 View, service를 결정하여 전달)
    domain
    	BridgeEnum (플레이어가 선택한 방향, 생성된 다리는 1or0, 건널수있는지) 
        BridgeGame (다리 건너기 게임을 관리하는 클래스)
    exception
    	BridgeGameException (사용자 잘못된 입력의 예외처리를 관리하는 클래스)
    service
    	BridgeService (다리의 길이만큼 다리를 생성해준다.)
        				서비스로 분리를 함으로써 테스트코드를 작성하기 수월해졌다.
    view
    	InputView  (사용자 입력 클래스)
        OutputView (출력 클래스)
    Application(컨트롤러를 실행하는 클래스)
    BridgeMaker(다리를 생성해주는 역할)
    BridgeNumberGenerator(인터페이스, 상속을 위함)
    BridgeRandomNumberGenerator(0과1을 랜덤으로 뽑아준다.)

 

🎯 고민한 과정, 회고

• 주어진 클래스의 요구사항대로 객체가 그 일만 수행하도록 만들도록 분리하여 구현하는 부분

추가된 요구사항에 InputView, OutputView, BridgeGame, BridgeMaker, BridgeRandomNumberGenerator 이 있었는데 클래스별 세부 사항을 파악하고 의도에 맞게 구현하는데 시간을 많이 투자하였고, 배우는 것이 정말 많았다.
코드를 먼저 전체적으로 기능이 구현되게 작성한 후 확인해보니 BridgeGame 클래스가 도메인이 아닌 서비스에 있어야할 것 같은 생각이 들었다. 그러고 나면 domain에 생성된 다리를 관리하는 Bridge 클래스와 사용자가가 시도한 횟수를 담을수 있는 User 클래스를 둠으로써 domain, view, service를 결정하는 것이 수월할 것 같았다.

하지만 리팩터링을 하려고 보니 BridgeGame을 Bridge 와 User클래스로 분리하는 역할을 나누는것이 객체에 메시지를 보내는 것이 아니라 getter를 사용하는 기능만 된다는 것에서 객체스럽게 사용하지 않다는 생각을 하고 BridgeGame을 도메인으로 코드로 작성했습니다.

• 다음 내가 작성한 enum은 연관성이 있는 상수를 묶어서 활용하려고 했지만, 파라미터가 4개로 사용할수 없었다.

	UP_TRUE("U", 1, true, "O"),
    UP_FALSE("U", 1, false, "X"),
    DOWN_TRUE("D", 0, true, "O"),
    DOWN_FALSE("D", 0, false, "X");
    처음 구현한 Enum 클래스
    
    -> 파라미터 최대 3개까지만 허용 요구사항에 위반

• Enum의 상수와 get 메서드만 추가하여 같은 의미를 주는 것은 좋지만
  추가하는 과정에서 메서드의 길이가 길어지고 타입이 반복되어 쓰이고있다는 사실을 파악하고 3개로 줄이는 리팩터링을 진행하였습니다.

🚩 다음 목표

• Java Enum 재공부
• MVC 모델 재공부
• getter를 사용하는 대신 객체에 메시지를 보내자
• 리팩터링을 진행해보자 !

 

프리코스 과정을 마치며

이번 우테코는 정말 나에게 정말 많은 도움을 주었다. 프로젝트를 진행하고 있었기에 두 개를 모두 할 수 있을까 힘들었지만 프리코스를 하면 정말 시간 가는줄 모르고 재밌게 했던 것 같다. 피드백과 코드 리뷰 등 얼마나 중요한지도 알게 되었고 짧은 시간이지만 깊이 배운 것 같다.

 

🐣 [구현 코드 보러가기]

https://github.com/COBI-98/java-lotto/tree/EUNSH1

GitHub - COBI-98/java-bridge