[우아한 테크코스 5기] 사다리 타기 2단계 학습 로그

---

GitHub 저장소

STEP 2 목표

변경 사항

개선할 점

배운 점

궁금한 점

후기

---

📆 기간 : 2023.02.18~ 2022.02.25

사다리 타기타기

 

---

GitHub 저장소

사다리타기 2차 PR 깃허브 주소

---

STEP 2 목표

추가된 요구사항

• 사다리 실행 결과를 출력해야 한다.
• 개인별 이름을 입력하면 개인별 결과를 출력하고, "all"을 입력하면 전체 참여자의 실행 결과를 출력한다.

최대한 객체지향적으로 작성하고자 노력하였다.

Step1에서는 레이어의 무게가 너무 무거웠던 것 같다. 다른 레이어에 책임을 분할하면서 얇게 하려고 노력하였다.

---

변경 사항

Game

private Map<Name, Goal> prizeResult; 값을 갖는 Game 클래스이다. 처음에는 Game 클래스에서 사다리를 받아서 게임을 실행하고 결과값을 저장하여 후에 사용자로부터 값을 출력하는 역할이었다. 하지만 구현을 하다보니 Game 클래스가 점점 비대해졌고 하는 역할이 너무너무 많아졌다. 그래서 이를 한번 더 분리하기로 하였다.

이 과정에서 전략 패턴을 접목해보기로 하였다. 이 경우 사다리 타는 클래스를 외부에서 주입해주고, 테스트할 때에는 테스트용 사다리 타기 클래스를 주입해 테스트하면 좋을 것 이라고 리뷰를 받아서 처리해보았다.

GameStrategy 는 Ladder를 전달받아 시작점과 결과의 끝 점을 계산해주는 역할을 한다.

Game 클래스는 GameStrategy로 부터 받은 결과를 Name과 Result를 매칭하여 반환해준다.

 

 

GameStrategy

Map<Integer, Integer> playGame(Ladder ladder); 를 갖는 인터페이스이다. 이를 LadderGameStrategy에서 Override하여 사다리 타기 기능을 구현하였다.

LadderGameStrategy 에서의 구현 방법은 다음과 같다.

1. 시작 지점으로부터 왼쪽, 오른쪽 사다리가 있는지 확인한다.
2. 사다리가 존재한다면 특정 방향(왼쪽,오른쪽)으로 이동한다.
3. 사다리를 내려간다.
4. Height 까지 내려가면 값을 Map에 저장한다.

TestLadderGameStrategy 에서는 구현 방법은 다음과 같다.

1. 시작 지점 은 도착 지점이다. ex) 0번 지점 시작 → 0번 도착
2. 값을 Map에 저장한다.

 

Winner

Winner는 결과 값을 알고 싶은 사람의 값을 포장한 model이다.

처음 입력한 참여자 명단과 값을 비교하며 all 메세지 를 입력 받았을 경우를 검증한다. 처음에는 Player라는 이름으로 작성하였는데 숙취로 인해서인지 너무 대충 짰길래 다시 짰다.

---

개선할 점

TDD

TDD로 코드를 작성하는 것은 너무 어렵다. 어떤 범위에서 어떤 기능으로 시작해야할지 너무 막막하고 막상 구현하게 되면 생각대로 이루어지지 않는 경우가 많다. 내가 제일 많이 겪었던 실수는 TDD로 돌아가지 않는 코드 작성 → 프로덕션 코드 작성 → TEST코드에 해당하는 프로덕션 코드 뿐 아니라 그외의 코드들도 작성 하는 길을 잃는 코딩을 많이했다. 다음 미션에서는 제대로 생각하고 하려고 한다.

 

Test Code

TDD로 짜다가 길을 많이 잃었는데 그러다보니 TESTCODE를 조금 빈약하게 짠 경우가 많았다. 또한 assertThatnoException으로 확인을 자주 하였는데 출력 포맷이 변경되었거나 혹은 일부 값이 잘못 나오는 것을 확인할 수 없기에 조금 더 상세한 테스트코드 작성을 해야겠다.

 

Commit Log

나는 처음에는 Test → FEAT → REFACTOR 로 커밋 메세지를 작성하였다. 하지만 후에는 FEAT 하면서 TEST 코드도 한번에 작성하였다. Commit Log가 조금 난잡해지기도 하였다. 이를 개선해야겠다.

---

배운 점

equals & hashcode 재정의

생각을 안하고 있었던 부분이였다. 동등성과 동일성을 고려하지 않고 작성하였다.

 

일급 컬렉션

지금까지 사용한 일급 컬렉션을 정리해보았다.

 

원시값 포장

원시값 포장에 대해 정리해보았다.

---

궁금한 점

패키지 분리와 네이밍

지금까지는 MVC 패턴으로 MODEL, VIEW, CONTROLLER패키지만 사용해도 충분했다. 하지만 코드가 많아짐에 따라 이것으로는 분류하기가 어려워졌고 어떻게 패키지 네이밍을 하고 분리를 해야되는지에 궁금증이 생겼다.

패키지 네이밍은...정말 정답이 없습니다. 여러 기법들이 존재하긴 하지만, 그 안에서도 세세하게 사용하는 방식은 다 달라서요. 그래서 패키지를 만들때 어떤 규칙을 고민하기보다는, 명확함과 일관성, 단순성에 집중해보면 어떨지 싶습니다. 페어나 다른 크루에게 이야기하면 납득하겠다, 정도의 기준으로 분류를 해보면 좋을 것 같네요. 모델 패키지 내에서도 세부적으로 분리하면 좋을 것 같아요.

 

Domain에 의존적인 View

OutputView를 작성하다보니 Domain에 의존적인 내 코드를 볼 수 있었다. 뷰는 도메인에 의존해도 된다고 알고있지만 조금 유연하지 못한 것 같아서 해결하고자 하였다. 다른 크루들 같은 경우에 Controller에서 원시값으로 해체된 값을 제공해주는 크루도 있었다. 하지만 나는 포장을 한 이유는 최대한 원시값을 드러내지 않도록 한다고 생각을 하여 Controller에서 조차 해체할 필요가 없다고 생각하고있다. 그래서 이를 궁금해했다.

View와 Controller는 서로 다른 레이어이니 의존을 최대한 없애고싶은데, 원시값으로 해체해서 보내면 전달하기에 어려움이 있겠지요? 이런 상황에서 DTO를 사용해보는 것이 좋습니다.

 

DTO와 VO

리뷰를 받고 DTO 와 VO에 대해 궁금한 점이 많이 생겼다.

---

후기

단순하게 누가 ‘너 사다리 타기 게임 구현해봐’ 하면 바로 만들 자신은 있다. 그래서 쉽게 사다리게임 미션을 시작했지만 객체지향과 Test작성, 컨벤션 등 많은 요구조건을 만족시키면서 구현하는것은 생각보다 어려웠다. 내가 많은 부분에서 아직 부족하구나 라는 것을 느꼈다. 하나 하나 모르는 개념, 어려웠던 개념들을 정리하고 생각하고 직접 사용해본다면 성장 할 수 있겠지 라는 마음으로 공부해나가야겠다.