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

---

GitHub 저장소

구현 기능들

궁금한 것

코드 리뷰 

후기

---

📆 기간 : 2023.02.14~ 2023.02.18

사다리 타기타기

---

GitHub 저장소

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

---

구현 기능 목록

MVC 패턴으로 진행하였다. 크게는 사람 이름 입력 -> 사다리 높이 입력 -> 결과 출력 으로 구성했다.

사람

Name 모델과 그것을 일급 컬렉션으로 묶는 Names 모델을 만들어 사용하였다. 

Name과 Names 각자 모델 에서 이름 validation 처리를 진행하였다.

처음에는 InputView에서 검증과 분리를 처리하려 하였으나 이는 Names의 역할인 것 같아서 옮기게 되었다.

 

사다리 높이

InputView에서 높이를 입력받도록 하였다. 그리고 Int 값을 제외한 예외처리를 Integer.parseInt를 통해 진행하였다. 이는 InputView과 최소한의 검증을 해야한다고 생각하기 때문이다. (사실 어떤게 정확하게 잘하는건지 모르겠다)

LadderHeight를 이용하여 값을 포장하였다. 이번에 원시값 포장이라는 미션이 있었기 때문에 이렇게 진행하였고 모델에서 검증까지 진행하였다.

 

사다리

Ladder 모델을 만들었다. 이 모델은 Line 이라는 객체타입을 갖는 List를 가지고있다. 사다리의 전체적인 부분을 담고 있는 부분이다.

Line

사다리의 가로 행을 의미하는 도메인이다.

처음에는 list 의 타입을 boolean 형식으로 하였으나 enum 타입으로 변경하였고 조금 더 안정적인 구조로 만들었다.

Line을 생성하는데 있어서 Random값을 통해 생성을 해주었다. 그리고 다리가 2개연속 있으면 안되서 이를 for문에서 인덱스값을 줄이는 방식으로 진행하였다. 하지만 이부분이 마음에 들지는 않는다 .. 

 

ENUM

이번에 ENUM 타입을 사용하라는게 미션 요구사항이라서 처음에는 예외처리 메세지 전송용으로 사용하였다. 하지만 BOOLEAN을 포장하는 Status라는 상태를 하나 더 만들어서 만족스러운 코드가 된 것 같다.

---

궁금한 것

사다리 타기를 진행하면서 궁금했던 것은

ENUM 요구사항 사용위치

 - Line 도메인의 boolean 타입을 status로 포장하므로써 해결하였다.

 

TDD 진행시 커밋 단위

 - 처음에는 test -> feat -> refactor를 모두 한번에 구현해야할 것 같았다. 하지만 테스트 + 코드 + 리팩토링 한 사이클 을 커밋해도 될 것 같다. 난 test코드는 test로 무조건 해야되는 줄 알았다 .. 

---

코드리뷰

메소드 간결화

- 더 간결하게 할 수 있을 것 같아서 수정하게 되었다. 실수.

Validation 위치

- 난 지금과 같은 작은 size의 코드에서는 응집도를 떨어뜨릴 수 있다 하였다.

Depth

- 멍청하게 제약사항도 제대로 보지 않았다..

정규식 검증

- 학습에 추가적인 비용이 들며 제대로된 검증없이 사용될 수 있다고 한다.

ENUM 사용

- Line 클래스 boolean을 enum으로 포장하는 것

StringBuilder의 static화

- 현재는 상관없으나 두번이상 호출시 문제 발생

Test코드 성공/실패 모두 작성하기

- 조금 더 자세하게 작성하기

 

---

후기

TDD 는 어렵다. 지키기가 너무어렵다. 하다보니 흐름을 계속 잃는다 .. 

중간에 페어가 코로나에 걸렸다. 그러다 보니 혼자 하게 되었는데 혼자 하게 되다보니 코드를 제멋대로 짜는 경향이 있었다. 이를 고쳐야하는데 쉽지않았다.