[Board] 1차 제출입니다! #4

moonwhistle · 2025-03-20T07:05:14Z

4/27

정말 오랜만에 PR 드리는 것 같습니다...!

4월 한 달 동안 자격증(sqld, 정처기 / 둘 다 붙은 거 같습니다 ㅋㅋ 개이득) 시험도 치루고 시험 공부도 하고 공모전 준비도 하고 작은 프로젝트도 했습니다.
제가 이 걸 말씀드리는 이유는.. 그냥 요새 이것 저것 하면서 형 생각 많이 났습니다 ㅋㅋ
형 덕분에 많은 것들을 배웠고, 항상 조언해주시고, 제가 막히는 부분도 잘 풀어주셨던 기억이 떠오르더라고요.
형 아니였다면, "갈피도 못 잡고 헤메고 있었을 텐데" 이런 생각이 가장 많이 들었습니다.
특히 공모전이나 작은 프로젝트에서 백엔드 파트를 혼자 맡아서 진행했는데, 헤메긴 해도 어찌 저찌 해냈습니다. 끝까지 해내고 나니까, 지금까지 배웠던 시간이 헛되지 않았다는 그 뿌듯함이 정말 컸고, 감사하다는 마음만 들었습니다.

써놓고 나니까 조금 오글거리긴 한 것 같은데, 형 덕분에 많이 성장했고, 정말 고마운 마음이 큽니다...!!
저도 형처럼 나눌 줄 아는 개발자가 되었으면 좋겠네요 ㅎㅎ

부담되지 않게 항상 감사하다는 말 전해드리고 싶었습니다!!..

항상 잘 되시길 기도하겠습니다. 그리고 항상 잘 되실겁니다...! 이재윤 파이팅!! 👍

[한 것]

정책적인 부분을 많이 고려하지 않은 것 같아, 이 부분 디테일하게 수정하였습니다.

Article이 삭제되면 Comment 도 삭제될 수 있도록 하였습니다. (생명주기를 같다고 보았습니다.)

직접 참조를 통해 ManyToOne, OneToMany, CasCade 활용해서 기능 구현하였습니다.

Member 삭제되면 Article, Comment 의 articleId 값이 null(= 알 수 없는 유저) 로 바뀌도록 하였습니다. (생명주기가 다르다고 보았습니다.)

memberId 간접참조하였습니다.
event 발행을 통해 memberId 값이 null로 바뀌도록 하였습니다. -> memberService 에서 articService 와 commentService 를 참조하면 참조관계가 너무 복잡해질 것이라고 생각했습니다. 또한, 좋아요 기능이나 다른 부가 기능 구현 시, 관계가 꼬일 수도 있다는 생각이 들었습니다.
event 발생 시, @Transaction 을 통해 rollback 처리 되게 구현하였습니다.
동기 처리 진행하였습니다. (비동기 처리 시, 회원은 삭제 안되고 게시글의 memberId 값이 바뀔 수 있음)

테스트 코드 모두 작성하였습니다 ! -> restDocs 적용하려고 하였으나, 코드 수정하면서 바뀔 부분이 많이 생길 것 같아 나중에 하겠습니다...!

paging 구현하였습니다! 처음 해 보는데, 이 부분 피드백 남겨주시면 감사하겠습니다!
- no-offset paging , offset-paging 둘 다 구현하였습니다!

exception 재활용을 위한 인터페이스 분리, 비밀번호 encryption 등 코드 리뷰에 달린 모든 부분 반영하였습니다!

동영상 추천 감사합니다 !! 정말 제 케이스하고 찰떡같이 똑같은 부분이라 항상 도움 많이 되는 것 같습니다 ㅎㅎ

[해야할 것]

테스트 코드를 조금 급하게 짜서, 변수 명이나 짜잘한 부분들이 미흡한 것 같습니다. 계속 수정하겠습니다!
캐싱을 공부하고 있는데, 대표적으로 메모리 캐시(Map, ConcurrentHashMap) / MyBatis 1차/2차 캐시 / 외부 서버 캐시(Redis) 가 있다는 것을 알게 되었습니다. 메모리 캐시 빼고 모두 써보고 싶긴 한데, 적용해봐도 괜찮을까요?? 굳이 이건 적용 안하고 다른 부분을 해봤으면 좋겠다 하시는 부분이 있다면 추천 부탁드립니다!!
시험 끝나고 나서, 좋아요 기능과 즐겨찾기 기능 구현해보겠습니다!

3/20

오랜만에 처음부터 만들어 보니, 헷갈리거나 까먹은 것들이 많아 정리하며 구현하였습니다.!
어느 정도 개념 잡혀서 더 빠르게 구현할 수 있었습니다.

[한 것]

member, article, comment 도메인 구현하였습니다.
article, comment 모두 간접참조를 통해 도메인 구현하였습니다.
jwt 로그인 로직 구현하였습니다. - (auth0 라이브러리 사용하였습니다.)
interceptor, resolver 구현하였습니다.
더미 데이터를 만들기 위해 load 패키지를 따로 파서, 더미 데이터를 집어넣었습니다.
스웨거 처음으로 적용시켜 보았습니다. - (아직 세팅할 것이 더 많아보입니다.)

[해야할 것]

추가로 테스트 코드 모두 구현하고 RestDocs 적용시켜 보겠습니다.
N+1 문제를 해결해 보고 싶은데, 공부해 보니 간접 참조를 하면 N+1 문제가 생기지 않는다고 들었습니다. -> 직접 참조 방식으로 도메인 로직 변경하여 문제를 해결하는 것이 좋을까요? 문제를 해결한다면 @EntityGraph, 쿼리 사용, batchSize 설정 이 셋 중에 어떤 것으로 하는 것이 좋을까요!?!?
앞으로 미션 진행하면서 추가로 학습할 부분이 있다면 알려주시면 감사하겠습니다...!

회원 가입 시, jwt를 발급하여 바로 로그인 할 수 있도록 로직 구현

openAPI 를 이용한 swagger를 세팅하기 위해 버전 다운그레이드

sosow0212

안녕하세요~

자바 멘토링 할 때가 어제 같은데, 이제는 새로운 것도 적용해보고 아주 빠르게 성장하고 있으시네요 인상 깊습니다!

이번에는 JPA 사용과 매핑 관련해서 고민이 많으신 것 같아서 그 부분을 중점적으로 남겼고 추가적으로 구조에 대해서 리뷰를 남겼습니다.

그리고 N+1 문제에 대해서는 JPA의 동작 방식으로 어쩔 수 없이 생기는 문제인데요. 이를 없애기 위해서 매핑 방법(간접참조, 직접참조)을 바꾸는 건 좋지 않다고 생각합니다.

매핑을 하는 방식도 여러 방법이 있습니다. 각 방법을 혼용해서 쓰기도 하고 하나의 방식만 쓰기도 합니다. 개인적인 생각으로는 JPA를 사용하는 이유를 생각해보고 JPA에서 추구하는 방식은 무엇인지와 같은 등장 배경을 생각해보시면 JPA가 어떤 목적으로 사용되는지 이해를 할 수 있고, 그렇게 되면 JPA의 의도대로 사용하는 직접적인 연관관계 매핑도 이해할 수 있게 됩니다. domain과 entity 관점에서 고민해봐도 괜찮을 것 같습니다.
이 방식에 대해선 생각해보시고 저한테 설명 주시면 좋을 것 같아요~

JPA를 쓰면서 공부하다 보면 연관관계 매핑을 잘하라는 글도 보게되고 어떤 글은 간접참조가 좋다라는 글도 보고해서 혼동스러울 수 있는데요.
두 방식 당연히 모두 사용하기 때문에 장단점과 차이점을 아셔야합니다! 그리고 비즈니스 상황과 앞으로 프로젝트가 추구하는 방향에 따라서 방법을 선택하시는 게 중요하다고 생각합니다.

어쨋든 매핑을 하다보면 N+1이 발생하는데 이 경우 FetchJoin을 사용하셔도 되고 Querydsl 등등 다양하게 해결할 수 있는데, 차이점도 직접 공부해보시면 좋을 것 같습니다! 어쨋든 N+1 때문에 참조 방법을 바꾼다는 건 저는 개인적으로 좋지 않다고 생각하는 입장입니다.

수고 많으셨고 궁금하신 부분 있으면 언제든 편하게 연락주세요!

++ 오 그리고 테스트가 누락되어 있네요! 추가해주세요~

docs/기능_구현_목록.md

src/main/java/com/board/article/controller/ArticleController.java

src/main/java/com/board/article/domain/Article.java

src/main/java/com/board/article/exception/exceptions/ArticleException.java

src/main/java/com/board/member/controller/auth/AuthController.java

src/main/java/com/board/member/controller/member/MemberController.java

src/main/java/com/board/member/domain/member/Member.java

src/main/java/com/board/member/service/auth/AuthService.java

sosow0212 · 2025-03-20T08:21:38Z

에고 실수로 Approve 눌렀네요! 이거 무시하시고 작업 쭉 해주시면 됩니다~

AuthService 에 있는 tokenProvider 로직 분리

sosow0212

마지막 사소한 것들만 수정해주세요! 그리고 의견을 몇 가지 여쭤봤는데 답변 부탁드릴게요! 너무 수고 많으셨습니다 ㅎㅎ 정처기 sqld, 프로젝트 등등 아주 바쁘셨을텐데 고생하셨습니다 👍

src/test/java/com/board/article/repository/ArticleRepositoryTest.java

src/main/java/com/board/comment/controller/CommentController.java

src/main/java/com/board/comment/exception/CommentException.java

docs/test.md

sosow0212 · 2025-04-28T07:39:22Z

docs/code_review.md

+* 페이지 번호가 있는 프론트 구현 시, 잘 맞는다.
+
+## 단점
+* OFFSET 100000 같이 뒤 페이지로 갈수록 느려짐 → 인덱스가 있어도 느림


👍 이것도 다른 방법으로 개선할 수 있긴해요!

다른 방법으로 개선할 수 있다고 하셔서 조금 찾아봤는데,
@Query 어노테이션을 통해 sql 문법을 작성하는 커서 기반 페이징이 맞을까요??

offset 은 처음부터 모든 column을 조회해서 속도가 느리지만 커서 기반 페이징은 특정 id 를 기준으로 해당 부분부터 조회하기에 빠르다는 것을 알았습니다..!

커서 기반 페이징이 개선할 수 있는 방식이라면, 다음 미션에서 해당 방식 적용해보겠습니다..!

src/main/java/com/board/article/domain/Article.java

sosow0212 · 2025-04-28T07:44:41Z

src/main/java/com/board/article/service/ArticleService.java

-    public List<Article> getAllArticles() {
-        return articleRepository.findAll();
+    public List<Article> getAllArticles(Long lastId, int size) {
+        Pageable articlePageable = PageRequest.of(NO_OFFSET_PAGING_PAGE, size, Sort.by(PAGE_SORT_DELIMITER).descending());


컨트롤러에서 pageable로 받으면 프론트측에서 사용할 수 있지 않나요?
프론트 정책에 따라 유연한 페이징 api를 사용하는 게 좋아 보일 것 같아서요!

페이지 정보를 포함하여 반환하도록 로직 수정하였습니다..!

sosow0212 · 2025-04-28T07:46:55Z

src/main/java/com/board/comment/service/CommentService.java

-        Comment comment = new Comment(memberId, articleId, request.content());
+    public Comment createComment(String content, Long memberId, Long articleId) {
+        Article article = articleService.getArticle(articleId);
+        Comment comment = new Comment(memberId, article, content);


pr 메시지에 Article과 Comment의 생명주기가 같다고 하셨는데, 삭제에 대해서만 같지 않을까요?
그러면 결국 제거 주기만 같을 뿐 생명주기가 같다고 할 순 없을 것 같아요! 결론적으론 Comment, Article 서로 다른 애그리거트라고 볼 수 있지 않을까요? 의존을 끊어낼 수 있어 보여서요! 혹시 다른 의도가 있다면 설명 부탁드릴게요~

sosow0212 · 2025-04-28T07:48:52Z

src/main/java/com/board/global/config/WebMvcConfig.java

    private final AuthArgumentResolver resolver;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {


인터셉터에선 현재 GET 요청에 대해서만 인증/인가를 진행할 거 같은데요
GET은 모두에게 오픈하고 POST, PATCH 같은 건 로그인된 유저에게 노출하고 싶다면 인터셉터를 수정해야할 거 같아요
이 부분도 변경해주세요!

src/main/java/com/board/member/service/member/MemberService.java

…제되는 기능 구현

sosow0212

수고하셨습니다~ 여기서 머지하겠습니다!
다음에는 댓글, 게시글 작성시마다 포인트 정책을 도입해보는 건 어떨까요? 그리고 조회수와 추천도 도입해서 인기글 산정까지 해보면 좋을 것 같습니다~ 많은 고민을 하신게 느껴져서 좋았습니다 고생하셨습니다👍

sosow0212 · 2025-05-19T01:25:58Z

src/main/java/com/board/article/service/event/ArticleEventListener.java

+    @Transactional
+    @EventListener
+    public void handleMemberDeletedEvent(ArticleDeletedEvent event) {
+        Long articleId = event.articleId();
+
+        commentService.deleteCommentByArticle(articleId);
+    }


게시글이 제거되면 댓글은 비동기로 백단에서 제거되어도 괜찮지 않을까요?

그게 아니더라도 한 번 비동기로 처리해보시는 건 어떨까요? 처리하시면서 쓰레드풀 설정도 해보시고 쓰레드풀 설정은 어떤 방식으로 하는지, 어떤 원리인지 설명도 같이 해주시면 좋을 것 같아요~

EventListner, TransactionalEventlistener 차이도 학습해보시고요!

sosow0212 · 2025-05-19T01:28:45Z

src/main/java/com/board/comment/controller/dto/reponse/PageCommentResponse.java

+        int pageNumber,
+        int pageSize,
+        long totalElements,
+        int totalPages


int, long이면 db에서 꺼낼 때 NPE가 발생할 수 있지 않을까요? (여기선 사실 크게 그럴 일이 없어보이지만 혹시 모르니깐요 ㅎㅎ)

moonwhistle added 22 commits March 12, 2025 16:20

docs: 기능 구현 목록 작성 및 member 도메인 exception 뼈대 구현

95886ea

feat: 회원 가입 기능 구현

efe1e89

회원 가입 시, jwt를 발급하여 바로 로그인 할 수 있도록 로직 구현

feat: 로그인 기능 구현

d35c083

feat: interceptor 기능 구현

10c682d

feat: 리졸버 구현

242e533

feat: 리졸버 등록

0a4e8bb

feat: 마이페이지 회원 조회 기능 구현

66961ed

feat: 마이페이지 유저 정보 수정 기능 구현

aa4cf67

feat: 마이페이지 계정 탈퇴 기능 구현

6d60d48

feat: 게시글 생성 기능 구현

8d6a824

feat: api 테스트를 위한 더미 데이터 추가 기능 구현

278f6bc

feat: 모든 게시글 조회 기능 구현

56e5bda

feat: 게시글 단건 조회 기능 구현

e2c2fac

feat: 유저 게시글 조회 기능 구현

8c4ab2e

feat: 게시글 수정 기능 구현

a4d046b

feat: 게시글 삭제 기능 구현

8c76392

feat: 댓글 등록 기능 구현

45e43f5

feat: 특정 게시글 댓글 조회 기능 구현

71d4d4c

feat: 특정 유저의 댓글 조회 기능 구현

65c75e4

feat: 댓글 수정 기능 구현

3f8b554

feat: 댓글 삭제 기능 구현

1ee872c

feat: swagger 세팅

f2e6d77

openAPI 를 이용한 swagger를 세팅하기 위해 버전 다운그레이드

sosow0212 approved these changes Mar 20, 2025

View reviewed changes

sosow0212 closed this Mar 20, 2025

sosow0212 reopened this Mar 20, 2025

sosow0212 changed the base branch from main to moonwhistle March 20, 2025 08:27

moonwhistle added 3 commits April 7, 2025 11:32

feat: ArticleRepositoryTest 구현

5205805

feat: MemberRepositoryTest 구현

77fffbb

feat: CommentRepositoryTest 구현

90637c5

moonwhistle added 22 commits April 8, 2025 23:13

refactor: prefix endpoint 를 위한 .yml 파일 작성 및 그에 따른 코드 수정

73545cc

refactor: error 코드 재사용성을 위한 전체적인 error 코드 구조 수정

9e49589

feat: memberServiceTest 구현

1b81f17

feat: CommentServiceTest 구현

ba530b0

feat: ArticleServiceTest 구현

00747c4

refactor: 토큰 로직 관련 책임에 따라 메서드 분리

8d5944b

AuthService 에 있는 tokenProvider 로직 분리

feat: AuthServiceTest 구현

912c548

feat: MemberControllerTest 구현

7ae9e51

feat: AuthControllerTest 구현

12703b3

feat: ArticleControllerTest 구현

a8fedce

feat: CommentControllerTest 구현

d91b26e

feat: offset paging 기능 구현

56eb314

feat: no-offset paging 기능 구현

37b8313

fix: http method 검증을 통해 비회원도 게시글을 조회할 수 있도록 로직 수정

34eaf88

refactor: interceptor allow uri 명시적으로 변경

3537df3

feat: 비밀번호 암호화 기능 구현

4b913db

refactor: DDD 설계를 통한 로직 구조 변경

07cb5e0

refactor: Member 역참조 수정 및 테스트 코드 수정

c4b57e4

refactor: Comment 역참조 수정 및 테스트 코드 수정

78137cc

refactor: Article 역참조 수정 및 테스트 코드 수정

b9430f7

feat: Article 삭제 시, Comment 도 같이 삭제되는 기능 구현

fcc6f76

feat: Member 삭제 시, Article 작성자와 Comment 작성자 알 수 없음 처리 기능 구현

3eabf85

sosow0212 requested changes Apr 28, 2025

View reviewed changes

moonwhistle added 5 commits May 17, 2025 23:39

refactor: get / find 컨벤션에 따라 네이밍 리팩토링

d0b81ea

refactor: article paging 반환값을 페이지 정보를 포함해서 반환하도록 리팩토링

5e146bc

refactor: comment paging 반환값을 페이지 정보를 포함해서 반환하도록 리팩토링

e1c23f1

docs: 코드 리뷰 생각 정리

aaade75

feat: article / comment 객체 연관관계를 간접참조로 수정 및 article 삭제 시, comment 도 삭…

be18184

…제되는 기능 구현

sosow0212 approved these changes May 19, 2025

View reviewed changes

sosow0212 merged commit c7968fc into GrowingMates:moonwhistle May 19, 2025

[Board] 1차 제출입니다! #4

[Board] 1차 제출입니다! #4

Uh oh!

Conversation

moonwhistle commented Mar 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sosow0212 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sosow0212 commented Mar 20, 2025

Uh oh!

sosow0212 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sosow0212 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

moonwhistle commented Mar 20, 2025 •

edited

Loading

sosow0212 left a comment •

edited

Loading