[27일차 작업일지] 드디어 제출을 했다!! (배포 링크, 발표, 문서)

 

오늘 하루 일정

# 하루 일정
# 오전: 배포 준비
# 오후: 발표 준비 -> 멘토링 -> 영상 편집 -> 제출 완료!!

 

배포 링크

http://danimbucket.s3-website.ap-northeast-2.amazonaws.com

 

PPT

https://docs.google.com/presentation/d/1VXAVnWGtVGlYI1v-uZeQH3e40cyODkTnVtcs2bjVmUE/edit?usp=sharing

다님

 

발표 관련 문서

https://sunset-mammal-6af.notion.site/40-Team18-4b54d24c7ef24e25b81cf4e70869130a

 

발표 내용

댓글 기능을 만들 때 생겼던 트러블 슈팅에 대해 얘기하려고 합니다. 댓글의 내용 변수인 Content가 Post를 보낼 때는 정상적으로 response 받을 수 있었지만, Get 요청을 보내면 null이 나오는 오류가 생겼습니다.

그래서 Patch를 사용해서 다시 확인했더니 Content를 null값이 아닌 정상적인 응답을 확인할 수 있었습니다. 그래서 이제 DB에 저장이 제대로 되지 않는 것 같다고 판단하여 H2를 들어갔더니, 전혀 저장이 되지 않고 있음을 확인했습니다.

시간이 따라주지 않아 당시에는 Set을 사용하여 저장했지만, Set은 Entity의 값을 변경한 의도를 파악하기 어려운 단점이 있어 사용을 지양해야 되는 방법입니다.

이와 같은 문제가 Member 엔티티의 nickName과 memberId를 받는 데도 발생했습니다. nickName과 memberId를 받아 저장했어야 됐는데, 마찬가지로 null이 들어와 또 Set을 사용하게 됐습니다.

통신 테스트를 위해 급한 불을 끈 뒤 이 문제를 제대로 해결하고자, 더 좋은 방법이 없을까 알아보았습니다.

Dto를 Entity로 변환시키지 않아 발생한 문제였고, 이를 해결하기 위한 방법으로는 MapStruct나 빌더 패턴을 사용하는 방법이 있습니다.

Dto 클래스를 사용하는 이유에는 서비스와 데이터베이스가 독립적이어야 하기 때문입니다. 데이터베이스의 변경사항이 있으면, Entity를 사용하는 서비스 단에도 변경이 일어날 수 있습니다.

그리고 클래스가 DTO로써 사용되는 메소드와 Entity로써 사용되는 메소드가 공존하게 됩니다. 이런 점에서 관심사가 분리되지 않고, 클래스의 결합력이 높아지게 됩니다.

프로젝트가 끝난 이후에 결합력을 낮추기 위해 빌더 패턴을 제대로 사용하여 사용 목적이 뚜렷한 직관적인 API를 만들 예정입니다.

 

진행 상황

프로젝트는 화요일까지 진행하지만, 오늘 자정까지 모든 프로젝트 관련 문서와 영상을 제출해야 돼서, 오늘 전부까지 전부 끝냈다.

오늘까지 끝낼 수 있을까 걱정했는데, 처음엔 어영부영 끝냈다가. 멘토링 후 조언 바탕으로 같이 PPT 대본도 만들고 개인 기술 발표의 내용도 뭘 했는지가 아니라 트러블 슈팅을 위주로 해야 돼서 대본도 전체적으로 바꿨다.

아직 완전 끝난 건 아니지만, 그래도 끝이 다와가는 것 같아서 기쁘다.

 

이제 내일부터 화요일까지는 댓글 빌더 패턴 작업을 해야지!!