[우아한 테크코스] 프리코스 3주차 회고

🍀 미션에 들어가기 이전에..

2주차 공통 피드백에서 내가 놓친 부분 찾기

- 마크다운은 프로젝트를 소개한다. 어떤 기능을 담고 있는지 기술해야 한다.

여태까지 마크다운을 잘 신경쓰지 못한 것 같다. 마크다운은 우테코 측에서 제공하고 있는 내용으로 충분할 것이라고 생각하기도 했고, 코드 구현에 급급했던 것 같기도 하다.

 

- 기능목록을 너무 자세히 작성하지 말 것

메서드명, 클래스명까지 작성하지 않아도 된다고 한다. 무조건 자세히만 생각하는 것이 능사는 아닌 것 같다. 나 역시도 저번주차에 클래스명까지 썼다가 여러번 문서를 수정해야 해서 어려움을 겪은 적이 있기에 이에 대해서 동감했다.

 

- 변수 이름에 자료형을 사용하지 않는다.

이제까지 계속 해오던.. 버릇이다.. 이제는 하지말자!

이에 관해서 slack 에서 찾아보다가 friendsList 였던 변수명을 자료형을 set 으로 바꿨다고 해서 friendsSet 으로 바꿀 것이냐는 비유를 들었을 때 단번에 이해가 가서 이 버릇을 반드시 버려야겠다고 생각했다.

 

- 테스트코드 짜는 방법에 대한 자료

@BeforeEach 사용하기

 

 

🍀 이번주차에 개선한 부분

- mvc 패턴을 지키기 위해서 model 단에서 view 단을 호출하지 않도록 개선

이전주차까지는 controller 의 코드를 깔끔하게 가져가야 한다고 생각해서 view 를 호출하는 코드를 전부 model 단에 넣어뒀었다. 그런데 이렇게 하니 역할이 명확하게 분리되지 않는다고 생각했고, 모델의 테스트코드를 짤 때도 일일이 inputstream 을 사용해야 하는 어려움이 있어서 이를 개선하게 되었다.

 

🍀 이번주차에 느낀점

이번 주차 미션 공유 메일에 적힌 것과 같이 클래스의 분리와 도메인 로직에 대한 단위 테스트를 작성하는 연습에 초점을 두어서 느낀 점을 기술하고자 합니다. 우선, 클래스 분리를 생각하다보니 미션 진행 중 처음으로 상속을 사용하게 되었습니다. 예를 들어, 당첨 번호의 유효성을 검사하는 클래스와 보너스 번호를 검사하는 클래스는 범위 확인이나 기존의 숫자와 겹치지 않아야 한다는 점에서 공통적인 로직을 갖지만, 다른 로직을 갖는 부분들도 존재했습니다. 따라서 처음에는 한 클래스 내부에 오버로딩을 통해서 구현하고자 했지만, 이는 가독성을 해치고 명확하지 않은 메서드명을 낳는다고 생각해 상속과 클래스의 분리를 통해서 이를 해결했습니다. 이를 통해 각 클래스의 역할과 명분을 명확히 하는 것이 코드를 짜는 입장에서도, 읽는 입장에서도 혼돈을 주지 않을 것이라고 생각했습니다. 공통적인 부분은 확실하게 묶되, 차이가 있는 부분은 공통적인 부분을 중심으로 명확한 분리가 필요하다고 생각했습니다. 또한 도메인 로직에 따른 단위 테스트를 작성하며 지난 주차에 언급했듯, 메서드 간의 결합도에 대하여 고민해보고, 그 강도가 강할 경우에는 어떻게 완화시킬 수 있을지 고민했습니다. 이번주차에는 기능 구현을 하며 그에 따른 테스트 목록 사항도 정리하여 진행해 나갔습니다. 기능에 해당하는 코드를 짠뒤 테스트 코드를 짜는 버릇을 들이니 제가 짠 코드를 돌아보며 1. 어떤 기능을 검증해야 할지 고민하며 메서드의 역할을 고민하게 되었고, 2. 검증하는 과정에서 기능 구현에 해당하는 코드가 효율적인지 고민하게 되었습니다. 이번 주차에는 저번주차와 다르게 테스트코드 역시도 기능 구현에 들이는 시간만큼 정교하게 구현해내고자 노력했습니다. Assertions의 다양한 메서드를 사용했고, @BefroeEach 와 @DisplayName을 사용하기도 했습니다. 뿐만 아니라  기존에는 오류를 직접 입력값을 입력해 잡아야 한다는 생각에 한계가 존재한다고 생각했는데 테스트코드를 이용하다보니 예상치 못한 오류도 해결할 수 있게 되었고, 상대적으로 기능 구현을 하는 코드를 짜는 데에 있어 부담감이 덜해진다는 생각이 들었습니다.