[프로젝트]Team.II_JPA를 활용한 Newsfeed 구현

관련한 링크 및 자료

#1 프로젝트 발제 노션

[Spring 3기] 뉴스피드 프로젝트 | Notion

#2 팀 노션 페이지

II조 | Notion

#3 프로젝트 깃허브 / 발표 시 사용한 PPT

GitHub - ii-news-feed/ii-news-feed-backend

프로젝트 PPT.pdf

1.42MB

 

---

프로젝트 진행 (24.10.18-24)

24-10-18	24-10-21	24-10-22	24-10-23	24-10-24
팀 인사 후 서류 작성 및 역할 분배 (API 명세, ERD, 와이어 프레임)	Restful한 API 설계 수정 및 깃허브 이슈, 코드 작성	코드 작성 및 팀 코드 수정	코드 작성 및 팀 코드 수정, 튜터 님의 코드 리뷰	팀 발표 (ReadMe, 발표 시연 영상, PPT 준비)

 

진행 과정에서의 문제

• API 명세서와 ERD를 먼저 작성하고 와이어 프레임을 작성해서 실제로 구현해야 할 API나 에러 사항이 누락되는 실수 가 있었다.
  ▶ 다음 번에는 와이어 프레임을 먼저 작성하여 구현할 것을 확실히 해야겠다는 생각이 들었다.
• 튜터님께 허락을 맡고 다음 과정을 진행해야했기 때문에 애매하게 붕 뜨는 시간이 자주 생겼고, 체감상 코드는 하루에서 이틀 사이로 작성한 탓에 자잘한 실수가 많았다.
  ▶ 남는 시간에 팀원들과 조금 더 소통하고, 설계나 코드(코드 리뷰)에 대한 이야기를 나누었다면 더욱 유익한 시간이 되었을 것 같다.
• 당일날 발표 자료를 준비했기 때문에 미흡한 점이 많았다.
  ▶ 발표자료는 최소한 그 전날 준비하는 것으로 한다. 또한 발표 문서에는 API 명세, ERD, 와이어프레임(와이어 연결을 빼먹지 않도록 주의), 트러블 슈팅이나 회고, 각자 어려웠던 코드, 구현하기 힘들었던 것, 특별히 신경썼던 것을 함께 집어넣는 것을 생각하자.
• Issue나 Pr, 코드 작성(변수나 메서드명, DTO 사용 등)시 컨벤션이 부족했던 것 같다.
  ▶ 미리 필요한 컨벤션을 생각하고 팀 노션에 첨부하여 큰 시간을 들이지 않고, 프로젝트를 진행할 수 있도록 해야겠다.

진행 과정에서 좋았던 점

• 시간이 많이 들었지만 문서화를 꼼꼼히 진행한 덕에 API가 많이 변경되는 일 없이 진행할 수 있어 편했다.
• Restful한 api, issue를 이용한 github 브랜치 이용 같은 것을 튜터님께서 초기에 설명해주셔서 이해하기 쉬웠다.
• 슬랙이나 화면 공유 등 팀원끼리 원활한 소통이 가능했다.
• 마지막에 튜터님이 코드 리뷰를 통해 전체적으로 코드를 봐주셔서 배울 점이 많았다.
• 팀 별 발표를 통해 다른 팀의 기능과 사용한 스킬을 보고 참고할 수 있었다.

---

개인적인 코드 개선 방안

• Setter 대신 create, update 메서드를 Entity에 따로 만들 것
• Dto를 자잘히 분리할 것(LoginRequestDto, SignupRequestDto)
• HttpRequest, HttpResponse는 Controller에서만 사용할 것.
• Validation을 활용할 것(@Not Blank 등)
• Password 인코딩은 Service가 아닌 Entity에서 처리
  (Password와 다른 Column들을 분리해서 처리하지 말고, 생성자 하나로 처리)
• @Validation과 Errorcode를 따로 커스텀하여 관리할 것
  (다만 Errorcode의 경우, Log를 찍든지 해서 에러가 발생한 곳을 확실히 파악할 것)

공부가 필요한 사항

• ArgumentResorver
• Github branch와 issue 관리
• 커스텀 validation, Error
• DDD, Aggregate 방식
• N+1 해결방안
• 이미지 파일 올리는 방식(Server, Client)
• @Scheduled 사용(자동 delete)
• Open API 다루기
• Log

---

트러블 슈팅

1) email과 password @Pattern validation error가 적용되지 않는 경우

 

Password Encoding 문제

validation을 Entity에 적용하여 passwordEncoder로 넘어간 상태에서 에러가 발생되기 때문에

실제로 적용한 정규표현식이 제대로 작동되지 않는 문제였다.

▷ validation을 RequestDto로 옮겨 적용한다.

▷ Controller 파라미터에 @valid 어노테이션을 적용한다.

 

2) 회원가입 시 Long type error 발생

 

email과 password를 받는거라 Dto와 Entity에서는 전부 String이 들어가야하는 코드인데도

Long type이 아니라 Error가 난다는 메세지가 떴다.

알고보니 테스트하던 Postman의 메서드를 Post가 아닌 Get으로 설정해두는 바람에

API uri가 같은 회원 조회 Controller에 값이 들어가게 된 것이었다.

 

3) update Name이 이상하게 들어가는 문제

 

회원 이름 수정 Api을 작동시키면 json이 {name : kim}으로 나오지 않고

{name : {name;kimv}} 이런 식으로 들어가는 문제가 발생했다.

@RequestBody 파라미터 값에 String을 넣어 발생하는 문제였다.

▷ 처음에는 Map으로 넣어 작동시켰으나, 이후 NameUpdateDto를 따로 만들어 넣었다.

 

4) 이름, 비밀번호 변경 시 UpdateAt이 변화하지 않는 에러

 

Entity의 메서드로만 일부 Update를 처리하고 Entity 자체가 저장되는 save를 명시하지 않았기 때문에 발생한 문제였다.

save를 명시하지 않으려면 UpdateAt에 @LastModifedDate를 적용하면 된다.

적용해도 수정일이 자동으로 변화하지 않는다면 Update메서드에 @Transectional이 붙어있는지, 

mainApplication 에 @EnableJpaAuditing 기능이 적용되어 있는지 확인한다.