우테코 프리코스 3회차 회고록

다른 글들

우테코 7기 프리코스 1주차 회고

 

우테코 프리코스 2회차 회고록

 

우테코 프리코스 4회차 회고록

우테코 프리코스 최종 코딩 테스트 회고

 

들어가며..

GitHub - changuii/java-lotto-7: 우테코 프리코스 3주차

 

이번 주차에는 우테코 디스코드에서 여러 사람들과 코드 리뷰를 하면서 피드백받은 내용들을 정리해두고 이를 프로젝트에 적용하기 위해 노력했다.

1. 상수들을 그대로 코드에 작성해서 사용하는 것이 아닌 의미있는 상수를 선언해두고 사용하자
   • 이를 통해 코드의 의미를 더욱 명확하게 전달할 수 있다.
2. view의 역할을 좀 더 고민해보자.
   • 어디까지가 뷰의 역할이고 어디까지가 도메인의 역할인지..
   • 예를들면 도메인의 데이터를 뷰가 출력할 상태로 가공하는 것을 나는 도메인에 뒀는데, “출력”이라는 책임이 도메인에 있는 것이 이상하다고 판단하시는 분들이 많이 있었다.
3. util이라는 패키지명을 사용했는데, 이 이름이 의미 전달이 잘못되었던 것 같다.
   • 사실 나는 자바와 객체지향 프로그래밍을 배우면서 “유틸”클래스와 같은 이름을 가진 존재를 배운 적이 없었다.
   • 그래서 이를 학습해보았고, 객체지향의 개념에 좀 떨어진 느낌이었기 때문에 많이 활용하지는 않았다. (static 메서드들을 모아놓은 집합 클래스의 느낌이었다.)
4. 규칙 혹은 설정들을 모아놓은 집합 Config 클래스를 고려해보자.
   • 다른 분들의 코드들을 보면서 Config라는 이름의 클래스를 두고 여러 클래스에서 사용하는 것을 보았고 이 클래스는 요구사항의 많은 규칙들을 저장하는 클래스였다.
   • 이를 통해 규칙이 변경되는 경우, 이 Config 클래스만 수정해주면 되기 때문에 변경의 전파가 최소화된다고 판단했다.

3주차 로또

이번 미션에서도 공통 피드백을 먼저 분석하고 읽어본 후 개발에 착수했고 이전 주차의 실수를 다시하지 않기 위해 요구사항 명세를 최대한 “기능”에 초점을 잡고 작성했다.

이번 주차에서 많은 고민을 했던 부분은 내가 나만의 기준이 부족하구나, 메타 인지가 부족하고 상황에 따라서 감에 의존해서 개발한다는 느낌을 많이 받았고 나만의 기준과 메타 인지에 대해서 많은 고민을 했다.

특히 이번 주차부터는 요구사항이 복잡해지면서 이전처럼 많은 확장이라는 부분에 대응한 코드를 작성하기 힘들었다.

그래서 이번 주차에서는 명확하게 나만의 기준을 만들기 위해 노력하면서 고민도 많이 했던 것 같다.

첫 번째로 MVC 패턴과 관련된 내용이었다.

기존에 학습했던 스프링과 계속 코드를 겹처서 생각하다보니, 레이어드 아키텍처와 MVC 패턴간의 혼동이 자꾸 일어났고 이를 명확하게 하기 위해 많은 블로그들을 읽어보면서 이해하기 위해 노력했다.

1. MVC 패턴은 Model과 View 즉 비즈니스 로직과 사용자의 입출력을 분리하기 위해 나온 패턴이라는 것을 알게되었다. 이는 선배 개발자들이 많은 문제가 발생하는 부분에 대해서 이렇게 개발하는 것이 좋더라~ 라는 것이라는 것이라 생각했다.
2. 레이어드 아키텍처는 요청을 매핑하는 Controller, 비즈니스 로직을 담당하는 Service, 데이터베이스에 접근하는 Data Access Object로 나눠 구현한다.

이 두가지를 놓고 고민해보았고 결론적으로 나는 두 가지 모두 결국에는 선배 개발자들이 많이 발생하는 문제에 대해서 관심사의 분리를 미리 해두고 우리는 이를 따라가는 것이라 생각했다.

따라서 이 부분에 대해서 나는 현재 데이터베이스에 접근할 일도 없었기 때문에 레이어드 아키텍처는 사용하지 않았고 MVC 패턴으로 사용자의 입출력과 비즈니스 로직에 대한 분리를 목표로 계속 접근했다.

두 번째는 Validator, Generator와 같은 클래스들이었다.

처음 1주차 2주차에서는 많은 부분을 미래의 변경에 대비하기위해 Validator, Generator, WinnerSelector처럼 비즈니스 로직들을 분리시켜 이를 대비하도록 했다.

하지만 요구사항이 많아지고 복잡해지면서 이렇게 분리하는 것이 오히려 현재에 대해서는 많은 복잡성, 비용이 소모되는 것처럼 느껴졌다.

따라서, 꼭 필요한 부분들 이를테면, 도메인을 생성하는(기존의 정보를 통해 생성) Generator만 빼고 만들지 않기로 했다.

• Validator는 도메인의 요구사항 → 로또 번호는 6개여야 한다 → 이는 로또에 두고, 생성할때 예외를 발생시키는 것이 응집도를 높일 것, 이렇게 판단했다.

세 번째는 검증에 대한 부분이었다.

검증에 대한 부분은 크게보면

1. 도메인의 제약조건들,, 예를 들어 “로또 번호는 6개여야 하고 번호는 1 ~ 45 사이의 값이어야 한다”와 같은 도메인에 대한 내용
2. 입력에 대한 제약조건들,, 예를 들어 “번호의 입력은 , 를 구분자로 가지며 6개의 수를 입력하여야 한다.”같은 입력에 대한 내용

많은 고민끝에 위의 2가지 조건으로 분리했고 1번은 도메인에 2번은 InputView에서 InputValidator를 통해 이를 검증하도록 하는 것이라고 기준을 세웠다!

네 번째는 도메인, 모델에 관한 부분이었다.

어떤 것이 도메인이 되어야 할까?에 대해서 많이 고민해보았고 이를 “상태”라고 판단했다.

상태를 가져야 자신의 변수에 대해서 비즈니스 로직을 수행한다고 생각했다.

따라서 다음의 기준으로 개발했다.

1. 상태를 가지면서 비즈니스 로직이 존재한다면 도메인이다! → ex) Lotto, LottoBundle
2. 상태가 없으면서 비즈니스 로직이 존재한다면 컴포넌트다! → ex) LottoBundleGenerator, TimeGenerator

이번 주차에서 학습한 내용

1. enum, 기존에 그저 사용만했고 왜 탄생했는지 몰라 이를 학습하고 도입했다.
2. 유틸 클래스, 처음 들어보는 내용이었기 때문에 학습했지만 객체지향과 거리가 멀다고 생각해 도입하지는 않았다.
3. Static Factory Pattern, 리뷰를 하면서 이 패턴을 사용하는 분들이 많아 왜 사용하고 어떤 장점이 있는지 학습하고 이를 도입했다
4. Junit5 Parameterized Test, 파라미터화된 테스트를 학습했고 이를 통해 테스트 메서드를 줄이고 많은 경우를 테스트할 수 있었다.
5. DecimalFormat 클래스, 수를 출력할때 어떻게 포매팅할까를 찾아보다 발견한 클래스이다.
6. 메타인지, 회고를 작성하면서 메타 인지에 대해서 다시한번 이해하기 위해 공부했다.
7. Data Transfer Object, 도메인을 뷰에서 접근하고 있었는데 이를 DTO로 묶어내서 데이터를 안전하게 지킬 수 있다고 판단하여 이를 학습하고 도입했다.