우테코 - [회고] 3주차
3주차 미션 회고
3주차를 마치고 회고록을 써야겠다고 다짐했지만 정처기와, 오픈 미션에 하느라 늦게 작성하게 되었습니다.(핑계)
2주차 미션을 진행할 때부터 테스트 코드 작성 시점에 대한 고민이 많았습니다.
하나의 기능을 구현하고 곧바로 테스트 코드를 작성할 경우, 리팩토링이 많은 저에게는 테스트 코드와 패키지 구조 또한 함께 바뀔 것으로 예상되어 리팩토링 시간이 두 배로 늘어날 것 같았기 때문입니다.
그래서 2주차 미션 때는 이런 이유로 기능 구현 완료 후 테스트 코드를 작성했지만, 3주차 미션에서는 새로운 방식을 시도해 보기로 다짐했습니다.
테스트 코드의 의도에 대한 재고찰
3주차 미션을 수행하면서 저는 테스트 코드의 의도와 의미에 대해 다시 생각해 보았습니다.
기능을 한 단계씩 구현하면서 “내가 잘 구현한 걸까?”라는 불안을 테스트 코드를 통과함으로써 바로 확인할 수 있다는 점이 테스트 코드의 가장 큰 장점이라고 느꼈습니다.
그래서 이번에는 테스트 코드의 의도를 직접 느끼기 위해 하나의 기능을 완성할 때마다 곧바로 테스트 코드를 작성하는 방식을 적용했습니다.
작게 나누어 구현하며 느낀 변화
요구사항을 읽고 리팩토링 시 변경 가능성이 적은 작은 단위부터 구현을 시작했습니다.
처음에는 기능을 하나씩 만들고 테스트 코드를 작성하니 시간이 두 배 이상 걸렸습니다.
하지만 이 방식을 계속 적용하다 보니 테스트 코드를 작성하기 편한 구조로 기능을 구현하게 되었고,
“이렇게 구현하면 테스트 코드 작성이 더 편하겠지?” 는 질문을 자연스럽게 던지게 되었습니다.
예를 들어,
- 메서드 내부에서 다른 클래스의 메서드를 통해 값을 가져오는 대신
- 메서드 매개변수로 값을 전달받는 구조로 변경했습니다.
그 결과, 테스트 코드에서 원하는 인자를 직접 넘겨 테스트할 수 있었습니다.
물론 mock을 사용할 수도 있었지만, 저는 순수 자바만으로 검증하는 과정이 클린 코드 원칙을 지키고 있는지 확인할 수 있는 좋은 지표라고 생각했습니다.
테스트 작성 시점에 대한 스터디 의견
3주차 미션을 수행하기 전, 다른 분들은 테스트 코드를 언제 작성하는지 궁금해 스터디원들과 의견을 나누었습니다.
- 어떤 분은 기능 구현 전에 테스트 코드를 작성하는 분도 있었고
- 또 다른 분은 저처럼 기능 완성 후 안정화 과정에서 테스트를 작성한다고 했습니다.
이야기를 나누며 느낀 점은,
테스트 작성 시점에는 정답이 없다
는 것이었습니다.
중요한 것은 ‘언제 작성하느냐’가 아니라,
테스트를 통해 무엇을 확인하고 싶은지 명확히 아는 것이라고 생각했습니다.
단위 테스트에 대한 깨달음
2주차에 이어 “큰 테스트보다 단위 테스트를 작성하라”는 피드백에 대해 생각해보았습니다.
제가 느낀 단위 테스트의 강점은 다음과 같았습니다.
- 변경에 유연하다
- 리팩터링 후 수정할 가능성이 적다
실제로 리팩토링 중
- 작은 단위 테스트는 거의 수정이 필요 없었고
- 반면 많은 기능을 포괄하는 테스트는 자주 깨졌습니다.
또한,
하나의 메서드에 단위 테스트가 3개 이상 붙는다는 것은
그 메서드가 너무 많은 일을 하고 있다는 신호
라고 느꼈습니다.
그럴 때마다 자연스럽게 리팩터링을 진행했습니다.
그리고 모든 테스트가 통과해 초록불이 켜지는 순간,
콘솔 입력 테스트를 하던 때와 비교할 수 없을 만큼 코드에 대한 확신이 생겼습니다.
가장 많은 시간을 들인 부분 — 잘못된 입력 재시도 처리
이번 미션에서 가장 시간을 많이 들인 부분은 입력 오류 발생 시 재시도 처리였습니다.
처음에는
- 금액
- 로또 번호
- 보너스 번호
각각에서 예외 발생 시 try-catch로 처리하는 코드를 작성했습니다.
하지만 이는 중복된 로직이 3곳이나 존재하는 문제가 있었습니다.
그래서 “재시도 코드를 한 곳에서 관리할 수는 없을까?”라는 고민을 시작했습니다.
입력 전체를 try문으로 감싸 while문으로 반복하는 방식도 시도했지만,
이 경우 보너스 번호에서 예외가 발생하면 금액부터 다시 입력해야 하는 문제가 있었습니다.
요구사항은 “잘못된 입력만 다시 받기”였기 때문에 이 방식은 적절하지 않았습니다.
그래서 입력별로(금액, 로또 번호, 보너스 번호) 클래스를 분리하고,
다형성과 오버라이딩을 이용해 재시도 로직을 하나의 흐름에서 처리할 수 있는 구조를 고민했습니다.
그리고 재시도 전용 객체를 만들어,
그 안에서 구체적인 입력 클래스를 호출하도록 구조를 개선했습니다.
이 과정 덕분에
- 중복 코드가 크게 줄었고
- 다형성과 추상화의 진짜 의미를 체감할 수 있었습니다.
객체 내부에서 검증하는 구조에 대한 인사이트
3주차를 시작하기 전, 저는 검증 로직을 Validator 클래스에 따로 두는 것이 맞다고 생각했습니다.
실제로 다른 사람의 코드 리뷰에서도 그렇게 피드백하곤 했습니다.
하지만 이번 미션에서 제공된 Lotto 클래스를 보고 생각이 완전히 바뀌었습니다.
- Lotto 내부에 validate()가 존재하고
- Lotto가 스스로 가진 numbers 리스트에 대한 검증을 수행하는 구조였기 때문입니다.
이를 보며 느꼈습니다.
데이터를 가장 잘 아는 객체가 스스로를 검증하는 구조가
응집도가 높고 의도가 명확하다.
또한 이 구조가 프리코스 1주차의 체크리스트에 있던
‘일급 컬렉션’ 개념과 동일하다는 것도 깨달았습니다.
이 경험을 통해 일급 컬렉션이 왜 중요한지, 언제 쓰는지, 어떤 장점이 있는지 직접 이해할 수 있었습니다.
문서화에 대한 어려움과 앞으로의 목표
2주차 공통 피드백이었던 README.md 작성은 아직 익숙하지 않았습니다.
마크다운 형식 자체도 처음이라, 가독성 있게 정리하는 방법을 배우기 위해 여러 사람의 README를 참고했습니다.
특히 문서화를 어려워하는 저에게는 더더욱 도전이었지만,
남은 프리코스 기간에는 시간이 더 걸리더라도 꾸준히 문서화 연습을 하고 싶습니다.
README와 Pull Request에 글을 꾸준히 작성하며,
- 남에게 읽히는 글쓰기
- 코드 의도를 설명하는 글쓰기
- 문서화에 대한 자신감
을 개발자로서의 목표로 삼고 싶습니다.
