20221025 데일리 회고

✔️Date : 2022.10.25 TUE

---

What did you do?

✅ ERD 및 테이블 명세서 작성

: ERD를 작성하고, 테이블 명세서를 작성하였다. 작성하고 보니 확실히 도움이 되었다. 예전에는 그저 머리 속으로 필요한 것을 생각하고 제약 조건을 생각했다면, 문서로 작성하니 확실히 틀이 존재했고 이후에 코드를 작성할 때에도 도움이 되었다. 이 ERD와 테이블 명세서를 바탕으로 Entity Class를 구현했기 때문이다.  여러 명이서 프로젝트를 작업할 때, 문서화 되어있는 틀이 있으면 얼마나 도움이 되는지 알게 되었다. 또 굳이 여러명이 아니고 나 혼자 무언가를 복습하고 만들어 볼 때에도 이렇게 문서로 작성하면 굉장히 도움이 될 것 같았다. 이게 최종이 아니고 꾸준히 수정해나아가겠지만, 그래도 처음에 큰 틀을 잡고 구현함에 있어서 도움이 되었다. 

또 이렇게 틀을 잡아두면, 이후에 작업할 때에 우리끼리의 약속이 되기 때문에 그 또한 도움이 된다고 생각한다.

 

개인적으로 연관 관계는 항상 두 세번 생각하게 되는 것 같다. 다대일, 일대일, 다대다는 예시를 대입해보고 결론을 도출한 이후 어떤 것에 해당하는 지 확인하게 된다. 오늘도 Questions - Answers, Answers - Comments에는 예시를 머리 속으로 대입해보고 도출하였다. 하나의 질문에 많은 답이 달릴 수 있으나, 답이 여러 질문에 달릴 수는 없으므로 Qusetion : Answer = 1 : N 관계이다. 하나의 답에 여러 댓글이 달릴 수 있으나 하나의 댓글을 여러 답에 달수 없으므로(물론 복붙하면 되는 거지만, 어쨌든 다른 거니까!) Answers : Comments = 1 : N의 관계이다.이런 식으로 생각하고 도출하였다. 이 연관 관계는 이후 코드를 통해 매핑하면서 더 자세히 쓰게 될 것 같다. 이렇게 생각하는 건 그래도 금방 도출되지만, 매핑하는 것은 한 번 더 정리하고 들어갈 생각이다. 왜냐하면 mappedby나, JoinColumn등 적어야 할 것들이 존재하기 때문이다.

 

 

---

✅ API 명세서 작성

: API 엔트리 포인트와 메서드 그리고 Request Body와 Response Body를 정리하였다. 우선 Method는 프론트랑 백엔드랑 수정에 있어 차이가 있는 것으로 보여 두개 다 기입을 해두었다. 그리고 하위로 넘어가는 것들을 타고 타고 하위로 표시하였다.(근데 막상 회의가 끝나고 생각해보니 저 모든 것을 다 PathVariable로 받으면 성능에는 문제가 없을까...? << 이 문제는 내일 회의 때 같이 고민해 보는 것이 좋겠다. 우선 나도 이 부분을 좀 더 찾아봐야지.) 

우선 Postman으로 요청을 보내고 받는 것을 기준으로 생각을 하고 작성을 하였다. 이 또한 최종이 아닌 작업을 하면서 분명히 수정이 들어갈 것이다. 이 명세서가 중요한 것은 이렇게 uri와 메서드 등을 정해두어야 우리가 해당 요청에 맞게 MVC를 구현할 수 있고, 그에 맞게 프론트 분들도 화면을 구현하실 수 있기 때문이다.

---

돌아보기

: 오늘은 혼자서 작업하기 보다는 팀으로, 그리고 백엔드끼리의 회의가 메인이었다. 후.. 개인적으로 늘 생각하는 건데, 정말 소통은 어려운 파트인 것 같다. 백엔드의 부분을 프론트엔드 분들에게 설명하는 것은 어려웠다. 내일 설명하고 정해야 하는 부분들은 오늘 한 번 더 생각하고 정리해서 내일 설명하는 것이 좋을 것 같다. ⭐️어려울 수록 쉽게 설명하는 게 중요하기 때문이다! ⭐️

문서화 특히.... API 명세서는 정말 너무너무 어려웠고(Endpoint 생각, response Body 등등), 프론트에서 받을 데이터를 고려하는 게 어떤 부분인지 아직 어려운 것 같다! Body로 들어오는 것은 출력하는 것이고, Header로 공유하는 것이 아닐까? 하는 생각이 든다. 근데 그럼 이걸 어떻게 받아서 처리하는 거지...? Spring Security 때에 적어둔 어노테이션들도 다시 체크를 해 보았다. 왜냐하면, 글을 작성할 때 로그인이 되어있어야 하기 때문이다. 근데 매번 작성 할 때마다 로그인을 하는 게 아닌, 로그인이 되어 있는 상태를 유지해야하고 이것을 토큰으로 가지고 통신해야하는 것 같다. (스프링 시큐리티... 다시 공부해야겠다.. 너무 너무 너무 너무 어렵다.) 내가 생각하는 저 방식이 맞는 것인지 다시 한 번 체크해 봐야할 것 같다! 그리고 비밀번호 암호화 하는 것도! DB에 비밀번호를 저장하면 안되니까!

위의 문제로 좀 오래 토론 한 것 같다. 어떻게 로그인 된 정보를 알 수 있으며, 회원인지 판별할 수 있고 이것을 어떻게 요청에 보내고 받을 지에 대한 문제였다. 결론은 Header로 요청을 보내고 받는 게 맞는 것 같다로 정해졌으나 정확하지 않으니 이 회고가 끝난 이후 공부해야 할 것 같다.

그리고 API 명세서를 다 썼는데, 계속해서 나는 왜 좋은 자료들을 보게 되는 것일까...

좋은 예시들을 몇 개 보아서 이것은 내일 회의를 통해서 얘기해 보면 좋을 것 같다. 이게 아마 위에서 우리가 오랫동안 토론한 문제에 대한 답이 되지 않을까 한다.