ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • issue-tracker 피드백
    글또 2021. 6. 27. 23:49

    이번 미션은 marco와 함께 했다.

    기본 기능 crud는 각자 나눠서 개발을 진행했고,

    s3에 이미지 넣기, 메일 인증, OAuth는 짝 코딩으로 진행했다.

     

     

    리뷰는 소니께서 해주셨다.

     

     

     

    이번에 롬복을 처음 적용해 봤는데 너무 편하다.

    편해서 그런지 불필요한 생성자 등을 조심해야 할 것 같다.

     

     

    jwt를 암호화하는데 썼던 key 빈으로 등록해 사용하고 있었다.

    intercepter에서 jwt를 검사해야 했기에 key를 주입받아서 사용했는데 올바른 위치 인가하는 답변이다.

    합성은 자유롭다고 생각을 했었는데 만약 인증 방식이 바뀐다면? 추가된다고 해도 다른 인터셉터를 만들거나 해야 할 것이다. 확장 부분에서 깊게 생각하지 않았는데 좋은 지적이었다. util에서 key를 직접 가지고 있게 하던가 service로 빼야 할 듯하다.

     

    현재는 무조건 Bearer 토큰이라고 생각을 하고 있었는데 토큰 타입을 바꿔서 들어온다면?

    여기도 생각하지 못한 부분이었는데 예외를 터트리거나 다른 로직으로 가게 만들어야 할 듯싶다.

     

    빈으로 등록을 하지 않고 사용을 했었는데 이유는 이점을 모르겠어서 이다.

    테스트 코드는 인터셉터라서 어찌할 줄 몰라 작성하지 않았는데 확장성에는 분명한 이점이 있어 보인다.

     

    show 하는 일은 findById 였다. showAll은 DTO로 변환까지 해서 프런트로 바로 나가지만 이 경우는 그렇지 않았기에 show라는 이름은 어색하다는 것이다.

     

    isSameWriter도 내부에서 검사를 하고 아닐 경우 exception을 터트리는 구조였다. 

    기본 가정이 해당 유저가 자신의 코멘트를 수정하는 것이라 생각해서 그랬는데, 

    아무래도 boolean을 반환하는 것이 더 합리적일 것 같다. 다른 누군가가 이 메서드를 사용했을 때 boolean을 예상하지 exception을 예상하지는 않을 것 같기 때문이다.

    앞으로 도메인에서는 boolean을 반환하고 특정 메서드만 exception을 터트려야겠다.

    이 이야기는 저번 TIL에도 작성해 놨었다.

    https://gisungcu.tistory.com/242

     

    2021.06.22 기록장

    ToDo 책 읽기 지원 알고리즘 공부 미션 (로컬 로그인) Done 미션 (로컬 로그인) 책 읽기 Weekly goal 책 읽기 블로그 읽기 Feeling 오늘은 로컬 로그인을 구현했다. 이전 qna에서 했던 로컬 로그인을 똑같이

    gisungcu.tistory.com

     

    코멘트 수정 url 상으로는 rest 하게 하기 위해 issue의 id도 함께 주었다.

    하지만 같은 어그리게이트라고 생각하지 않았기에 issue에서 수정을 주도하지 않는다. 

    여기서 서로 다른 점이 나온다. 그렇기에 내가 잘못 생각을 했나 싶기도 했다.

    해결법은 검증절차를 진행해서 의미 있게 만들면 되는 것이다. 

     

     

    밑에 캡처본은 다른 분들의 pr에서 가지고 왔다.

    필드 주입은 빈이 먼저 생성되고 주입되는 것이라 컴파일 시점에 순환 참조를 잡을 수 없다.

     

    https://madplay.github.io/post/why-constructor-injection-is-better-than-field-injection

     

    생성자 주입을 @Autowired를 사용하는 필드 주입보다 권장하는 하는 이유

    @Autowired를 사용하는 의존성 주입보다 생성자 주입(Constructor Injection)을 더 권장하는 이유는 무엇일까?

    madplay.github.io

    인터페이스에는 구체적인 정보가 드러나게 하지 말자.

    object에서도 본 기억이 있다. 

     

    내가 JwtUtil을 만들 때 들었던 생각이다. 상태를 가지고 있지 않고 도구로서 사용을 하자는 것이었는데,

    나중에는 key 자체를 가지는 것이 더 자연스럽다는 리뷰를 받아서 service로 변경을 했다.

     

    나도 페이징을 하지는 않았다. 여러 개의 패치 조인 때문이었는데(패치 조인 시 페이징을 하면 메모리로 모든 데이터를 가지고 와서 하이버네이트가 페이징 한다. -> OOM), 영한님의 강의에서 보면 OneToOne이나 ManyToOne은 패치 조인으로 가지고 오고 OneToMany 같은 것은 +1 쿼리를 한 번 더 내보내서 가지고 오는 것이 낫다는 이야기를 해주셨다. 

     

    이번 미션에서는 업데이트 API가 많아서 고민했었다. 나는 update용 controller와 service를 만들었었는데, 조회와 조작으로 분리를 진행하는 기법이 이미 존재했다.

     

    나도 같은 OAuth 2개를 인스턴스로 초기화해서 사용하는데 이 부분을 학습해야겠다.

    lock 관련해서는 이번에 인프런에서 장애가 난 것을 유튜브에서 본 적이 있다. 

    쿠폰 사용량을 올릴 때 트래픽이 몰려서 전부 lock 되었다는 이야기 었는데, 아직 대용량 트랙픽을 제대로 공부해보지 않아 많이 궁금하다. 

     

     

    이 부분은 마르코가 이번 미션에서 가르침을 주었는데 DTO를 Entity로 변환하고 파라미터로 넘기는 것이다.

     

     

     

     

    lock과 중복 타입 빈 주입 방법을 공부하자.

    '글또' 카테고리의 다른 글

    Atdd [인수 테스트 -1 ]피드백  (0) 2022.01.22
    2021.11.25 기록장  (0) 2021.11.24
    airbnb 피드백  (0) 2021.06.07
    baseball 피드백  (0) 2021.05.17
    sideDish 피드백-2  (0) 2021.05.05

    댓글

Designed by Tistory.