순간을 기록으로

DTO와 엔티티를 분리하지 않아 발생한 무한 순환참조 에러 게시글 상세페이지를 조회했을 때 응답으로 제공하는 정보중에 댓글 정보도 있었습니다. 프로젝트를 진행하면서 많은 에러를 마주쳤고 그 중에 가장 기억에 남는 에러를 핸들링하는 주제를 가져왔습니다. 주제는 DTO와 엔티티를 분리하지 않아 발생한 무한 순환참조 에러입니다. 위 사진은 게시글 정보를 응답으로 주는 DTO입니다. 게시글의 경우 Post 엔티티와 PostResponseDto로 분리하여 문제가 없을거 같지만 사실 이것은 DTO와 엔티티를 분리하지 않은 상태입니다. 왜냐하면 필드로 Comment 엔티티를 노출하고 있기 때문입니다. 위 사진을 보면 Comment 엔티티는 필드로 Post 정보를 갖고 있습니다. 그리고 위 사진을 보면 Post 엔티티..

첫 번째 어려움. 사용자 요구사항, 테이블 명세서, API 명세서, 화면 정의서를 만들었지만 정확하다고 말하기 어려웠다. 교육해주신 분도 결국 개발하면서 바뀐다고 말씀해주셔서 일단은 큰 의미를 두지 않고 문서화를 했다. 두 번째 어려움. 그 다음에는 프론트와 백엔드 API 테스트 통신을 해야 했다. API 통신을 하려면 프론트엔드에서 요청을 보내면 서버가 요청을 받아 처리한 다음에 응답을 보내줘야 한다. 그래서 localhost를 외부로 공개하여 프론트엔드에서 요청을 보낼 수 있도록 만들었다. 내가 생각했던 방법은 하나의 테스트 컨트롤러를 가지는 스프링부트를 jar로 만든 다음에 로컬 pc에 실행한 다음 그것을 외부로 공개하는 것이었다. 그러면 프론트가 요청을 해당 컨트톨러로 보낼 수 있고 응답값을 확인..

테이블 명세서를 만들 때였다. 테이블 명세서를 작성하려면 테이블 들이 만들어져야 된다고 생각했다. 하지만 주어진 문서는 사용자 요구사항일 뿐. 우선적으로 스택오버 플로우에 필요한 도메인을 먼저 그려보고 거기서 테이블을 추출한 다음에 테이블 명세서를 만들어야 된다고 생각이 들었다. 하지만 처음하는 설계인 만큼 확신이 없어서 팀원분의 의견에 따라 테이블 명세서를 먼저 작성했다. 후에 느낀 것은 도메인을 먼저 만드는 게 중요하다는 것이다.