[우테코 프리코스 3주차] 로또 회고

이승우·2023년 11월 19일
post-thumbnail

3주차가 마감된지 열흘정도 된 것 같다. 원래 금방 올리려했는데 4주차 구현도 해야하고 학업과 코테를 병행하려니 너무 바빠서 늦게 올리게 됐다.
기억이 자세히 나진 않지만 소감문을 바탕으로 회고를 써보겠다.

1. MVC패턴의 이해

1.1 InputView의 역할은 어디까지인가

이번 로또 미션에 이전 미션과는 다른 요구사항이 추가되었다.

사용자가 잘못된 값을 입력했을 경우 다시 입력받는다

처음 요구사항을 받았을 때, 이 입력값 판별을 어디서 할까 고민이 들었다. view? controller? model?

곰곰히 생각해보니 이 요구사항은 로그인 로직과 비슷한 것 같았다.

이번학기 프로젝트를 진행하며 로그인 기능을 구현한 적이 있었는데, 보통 로그인을 시도할 때 빈 값이나 n자 이하로 로그인을 시도하면 웹사이트에서 바로 반응이 온다. 웹에서 판단했을 때 적절한 Input이 아니라면 서버에 접근조차 못하게 하기 때문이다.

유저DB까지 접근하는 것은 불필요한 비용이기 때문이다.
그래서 처음 구조는 InputView에서 기본적인 입력 유효성 검사를 하고, 객체에서 비즈니스 요구사항에 맞는 값인지 확인하는 검사를 진행하려 했다.

그런데ㅠ
한가지 함수는 한가지 기능만 해야한다라는 피드백이 있었고 여기서 또 고민에 빠졌다.

InputView는 입력을 받기만 해야하는가?

입력과 입력 안내 문구는 한 쌍인데, 이걸 두가지 기능으로 봐야하는 건지.. 아니면 하나의 기능으로 봐도 되는건지..
프리코스 내내 이런 구조를 신경쓰는데 시간을 모두 쓴 것 같다.

원래 계획은 로그인 로직처럼 구조를 잡았다가, 피드백을 보고는 기능을 아예 다 나눴다. (생각해보면 틀린 것 같기도 하다)

'이렇게 짜는게 어떨까?'것보다 일단 피드백을 충실히 반영해서 코드를 짜보기로 했다.
난 초보이고, 모든것을 배워야하는 입장이기에

1.2 model과 view의 역할 분리

이번 주차를 진행하면서 model과 view의 역할에 대해서 더 자세히 알게 된 것 같다.

앞서 말한 로그인 로직을 다시 언급하자면,

model에서 유효한 회원인지 확인하고, 이 회원이 유효한 회원인지, 비밀번호가 틀렸는지, 휴면회원인지 판단하여 View로 보낸다.

그런데 View로 보낼 때, model이 사용자에게 전달할 메시지까지 결정해서 주진 않는다.

예를 들면 유효한 회원이라면 1, 비밀번호가 틀렸다면 0 이렇게 나눠서 줄 수도 있다. (물론 이렇게 하진 않는다)

View는 Model과 약속한 규칙에 따라 결과값을 받고, 유저에게 보내줄 메시지는 View 자신이 결정한다.

그런데 난 2주차 때,

// OutputView 중 일부
    public static void displayRoundResult(String roundResult) {
        System.out.println(roundResult);
    }

이런 코드를 썼다.

객체에서 보여줄 메시지를 다 만든 다음, View에게 전달하고 View는 그걸 그냥 출력하기만 하는 형식이었다...
내가 이 코드를 쓴 이유가 있긴 했다. getter를 회피하려고..

무조건 getter를 쓰면 안된다고 생각해서 이런 방식을 택했다.

결과값 포맷팅은 View에서 하는 것인데 Model에서 해버렸다. 지나고 나니 이 부분이 가장 후회로 남는다.

리빌드 해볼 때 getter는 최소화하면서 각 컴포넌트의 역할에 맞게 메서드를 짜봐야겠다.

Model은 비즈니스 로직과 데이터 관리, View는 입력과 정보를 표시하는 역할

2. 테스트코드 작성

미션을 진행하면서 테스트 코드 작성에 신경을 많이썼다.

처음엔 핵심 기능 위주로 테스트 코드를 집중적으로 작성했다. 근데 작업하다 보니, "이 메서드까지 테스트 해야 하나?" 싶은 순간들이 많다.

사실, 중요해 보이지 않는 부분들은 좀 대충 넘어갔다.

그런데 테스트 코드의 진짜 목적을 다시 생각해보니, 내 방식이 좀 잘못됐다는 걸 깨달았다.

작은 기능들이 모여 큰 기능을 만드는 건데, 이 작은 부분들이 예상대로 돌아가지 않으면 큰 문제가 생길 수도 있기 때문이다.

이번 미션에서 나는 테스트 코드 작성을 제대로 해보자고 다짐했었는데, 막상 해보니까 제대로 못 한 것 같아서 아쉬움이 많이 남는다.

후반부에는 테스트 관련 커밋을 했는데, 구조를 변경하거나 클래스를 삭제하면서 테스트 코드가 누락되거나 삭제된 경우도 있었기 때문이다.

4주차 마지막 미션에서는 작은 기능부터 차근차근 테스트하면서, 큰 기능이 제대로 작동되도록 하는 테스트 코드를 꼼꼼히 작성해볼 생각을 했었다.

0개의 댓글