다른사람의 코드 분석해보기 # Spring auth - 미션 2주차

1번 레포지토리

https://github.com/next-step/spring-roomescape-auth/pull/21/files

 

@Value

->

 

@ConfigurationProperties

 

cookie 의 유효기간 값을 설정해보아도 좋겠네요!

토큰에 만료기간보다 1초더 줘서 토큰과 쿠키의 만료기간이 비슷하게 작동하면 좋읗 것 같네요!!

 

PasswordHasher

해당 클래스를 스프링 빈으로 관리하는 이유가 있나요? 빈으로 관리하는 것의 장점은 무엇일까요? 

테스트할때는 MockPasswordHasher로 처리하려고 스프링 빈으로 만들었습니다.

멤버 생성 테스트와 같은 테스트들에서는 암호화가 잘되는지는 관심사가 아니기 때문에 이런 부분은 빈으로 등록하고 나중에 mocking 하는게 편하다고 생각해서 빈으로 등록하였습니다.

 

application 계층

ui계층

ui하위에 dot 계층

domain계층

도메인하위에 레포지토리 계층

exception

 

Memberfixture

 

support 계층

@JdbcTest

@AutoConfigureTestDatabase

@BeforeEach

@AfterEach

var

 

 

assertThat(response).usingRecursiveComparison()

.ignoringFields("id", "time", "theme”)

 

reservationRecorder

Assertions.assertDoesNotThrow(()

AssertThatThrownBy(()

.isInstanceOf(

.isInstanceOf(

 

isNotEmpty()

.extracting(“

.containsExactlyInAnyOrder

 

isTrue();

).isFalse();

memberFinder

 

).isFalse();

isNotBlank();

 

.body("message", is("JSON parse error: 필수 값은 비어 있을 수 없습니다. startAt = "));

 

테스트 잘 작성해주셨네요 👍
실제 애플리케이션과 동일한 포트를 사용하고 있어 애플리케이션이 띄워져 있는 상태에서 테스트를 실행하면 실패하게 되네요!
서로 다른 포트를 사용하게 하는 것은 어떤가요~?

 

테스트는 별도로 포트를 두고, 포트를 test.resources의 폴더 아래 application.yml에 정의해서 컨트롤하면 좋읗 것 같아요!

 

http 응답스펙으로도 상태코드를 주지만, body로도 넘겨주면 HTTP 상태 코드 이외의 커스텀 응답 코드를 넘겨줘서 관리하기 좋다고 생각합니다. 이러면 좀더 세밀한 예외 혹은 응답 처리가 가능하다고 생각해요.

 

@ExceptionHandler({MethodArgumentNotValidException.class, IllegalArgumentException.class,

 

DateTimeFormatter.ISO_DATE);

 

현재 application 레이어에 있는 서비스들을 보니, 영속화 시키는 행위에 많은 용어가 쓰이고 있네요 (adder, saver, recorder...)
각각 네이밍이 나온 이유가 궁금해요!

 

처음에는 도메인에 맞춰서 서비스 이름도 변하는게 자연스럽다고 생각했어요.

사람은 새로운 사람이 추가된 것이라 Adder이고 예약 시간은 새로 저장된 것이라 Saver 처럼 작성하였습니다.

이러면 메서드 이름을 지을때도 자연스럽고 역할도 클래스 이름만을 보고 좀더 이해하기 좋지 않을까 하였습니다 ㅎㅎㅎ...

그런데 작성하다보니 어떤 것이 Adder인지 Saver인지 기준이 참 애매하네요.
저 혼자 작성할때에는 쭈욱 작성하면 되지만, 팀에서 일한다면 이런 네이밍 컨벤션 규칙을 잡는게 쉽지 않겠네요.

 

좋은 의견이네요 👍
개인적으로는 현재 미션에서는 예약, 예약 시간 등에 대해 단순하게 생성이라는 비즈니스가 있는 것 같은데 이에 대해 다양한 용어가 사용되면 오히려 혼란이 생길 수 있다고 생각했어요!
말씀 주신 것처럼 타인이 읽었을 때 모호함도 생길 수 있겠네요 :)

🚀1

현재 유즈 케이스 별로 서비스를 나누어 구현해주신 것 같은데요, 이렇게 구현하신 이유와 느끼신 장점 혹은 단점이 있을까요~?

 

유즈 케이스별로 서비스를 나눈 이유는 각 서비스들이 책임을 작게 가지게 해서 단순하게 구현하기 위해서입니다.

복잡하게 개발되어있는 것보다는 단순하게 개발되어 있는 것이 나중에 활용하기도 좋고 개발하기도 편하다고 생각해요.

장점은 빠르게 개발하고 유지보수 그리고 해당 클래스를 다른 클래스에서 사용하기 엄청 편합니다!
테스트 작성할 때에도 해당 기능만 테스트하면 되서 직관적이고요. 단순하게 만드는 것이 최고 장점이라고 생각해요.

단점은 아무래도 클래스가 많이 쪼개지다보니 코드가 많아지는 느낌도 있고, 프로젝트의 구조를 잘 나누지 않으면
아무래도 클래스들이 많다보니까 찾기 어렵더라구요 ㅎㅎ;
또 기능을 확장해가면서 어려움이 있는 것 같아요.
기존 Finder라는 클래스에 새로 기능을 추가할 지 아니면 별도의 Finder를 만들어야 할지 고민되는 부분이 생기더라구요.

 

요청값에 대한 검증을 아주 꼼꼼히 해주셨네요 👍
추후에 Spring Validation 을 통해 검증할 수도 있겠네요~!

Spring Validation 이나 Custom Annotaion으로 작업해보려고 합니다!