[TIL] 내일배움캠프 31일차 - 개인 과제 완성

 

 

오늘의 학습 키워드📚

개인 과제 완성

• https://github.com/SeungJun-Kwon/MyTodo

GitHub - SeungJun-Kwon/MyTodo: 스파르타 코딩클럽 Spring 숙련 주차 개인 과제

프론트를 구현하지 않고 백엔드만 구현한 건 처음이라 더 어려웠으면서 더 쉬웠다(?)

이번 과제의 목적은 4가지이다.

1. 회원가입, 로그인을 구현할 수 있어요.
2. 인증/인가를 이해하고 JWT를 활용하여 할일 및 댓글을 처리할 수 있어요.
3. JPA 연관관계를 이해하고 회원과 할일 그리고 댓글을 구현할 수 있어요.
4. 할일을 완료처리하며 상태를 관리 할 수 있어요.

4가지를 전부 완벽하게 수행했냐 하면 애매한 것 같다.

회원가입과 로그인을 구현했지만 정말 별 다른 기능 없이 구현했다.

인증/인가를 처음엔 Filter 없이 JWT만 헤더에 담아서 할까 했는데 결국 Filter를 추가해 인증/인가를 했다.
Filter라는게 처음엔 되게 어려웠는데 '요청의 거름망'이라고 생각하니까 어느정도 와닿기 시작했다.
로그인 페이지에서 로그인을 시도하면 유저 정보를 바탕으로 인증 객체를 얻고 JWT를 발급해 헤더에 담아 보낸다.
발급받은 JWT를 'Authorization'이라는 헤더에 담아 검증을 하고 다른 요청들을 처리할 수 있다.

JPA에서 생각보다 고민을 했었는데 제약 조건을 걸어야 하나 말아야 하나였다.
예를 들어 유저가 글을 작성했는데 해당 유저가 회원 탈퇴를 할 경우 해당 글이 삭제되어야 한다면 어떻게 구현할 것인가?
방법은 크게 두 가지가 있는 것 같다.

첫 번째는 Entity에 제약 조건을 걸어 유저 객체가 삭제되면 해당 유저를 참조하는 다른 객체들이 전부 삭제되는 것이고 두 번째는 유저 객체를 삭제할 때 다른 연관된 객체들이 있는지 탐색하고 삭제하는 메소드를 호출하는 것이다.
첫 번째 방법을 사용하면 Entity에서 제약 조건만 걸어주면 알아서 삭제되니 따로 구현할 필요가 없지만 유연함이 없어지고 데이터가 소실될 가능성이 존재한다.

두 번째 방법을 사용하면 그때그때 삭제해주면 돼 유연한 대처가 가능하지만 매번 쿼리문을 호출해야 하니 효율성 부분에서 떨어질 수 있다.

내가 내린 결론은 두 번째 방법을 사용하는 게 좋겠다는 생각이 들었다.
사실 데이터의 양이 엄청 방대한 것이 아니라면 쿼리문을 좀 더 호출하더라도 데이터의 안정성과 코드의 유연함을 지키는 것이 좋겠다는 생각이 들었다.
둘 다 절대 틀린 방법은 아니라고 생각한다.
근데 사실 요구사항에 유저 삭제나 Todo 카드 삭제가 없어서 결국 이 부분은 구현하지 않았다

어떤 객체의 상태 관리는 하기 나름인 것 같다. 이번 요구사항은 할 일을 완료했나?만 신경쓰면 돼서 boolean으로 상태를 관리했지만 만약 상태가 여러개라면? 모든 상태에 boolean을 달아주는 건 굉장히 비효율적일 것이다.
그래서 만약 상태가 더 많아질 경우 Http 상태 코드처럼 Enum으로 상태를 만들어서 관리하는 것이 좋겠다고 생각했다.

예를 들어 티스토리에서도 글이 신규, 작성 중, 수정됨, 임시 저장, 완료 등 여러 상태가 있는데 이를 10 = 신규, 11 = 작성 중, 12 = 수정됨 .... 99 = 완료. 이렇게 코드로 분류해서 상태를 관리하면 훨씬 편하고 가독성도 좋을 거라 생각한다.

그리고 한 가지 과제를 하면서 유의해야겠다 싶은 점은 RESTFUL한 API를 설계했는지 매번 고민하고 의심해야할 것 같다.
여러가지 규칙이 있다. 단수보다 복수, 동사보다 명사, _보단 -, 대문자는 X 등등...
나도 모르게 이런 부분을 놓칠 수가 있는 것 같다.

---

오늘의 회고💬

이번 개인 과제로부터 많은 것을 얻을 수 있던 것 같다. 개발자적인 사고를 하는 법, 문제를 해결할 때는 어떻게 해야 하는지, 요구 사항을 충족했는지 등 이전보다 더 값진 과제였던 것 같다.

 

내일의 계획📜

쉴 틈도 없이 당장 내일부터 팀 과제다 으악