[13] Spring - lv 5 내가 정의한 문제와 해결과정

※ 지난번 조별프로젝트에 대해서 리팩토링을 일부 진행했으며, 해당 부분에서 정의한 문제와 해결과정을 작성해보겠습니다.

 

📁️ 프로젝트 설명

https://kuk1938.tistory.com/184

[9] Spring - 조별프로젝트 뉴스피드 프로젝트(JPA)

 

 

 

1) 문제 인식 및 정의

뉴스피드 프로젝트 리팩토링)

- @Query 어노테이션을 활용한 nativeQuery 줄이거나 없애기

- 친구요청 상태값 String으로 비교 및 체크하는 부분 수정

 

2) 해결방안

문제1) @Query 어노테이션을 활용한 nativeQuery 줄이거나 없애기-  jpa에서 count() 집계함수를 설정하여 코드개선 적용※ 해결

 

- 기존코드

- 개선된 코드

 

 

문제2) 친구요청 상태값 String으로 비교 및 체크하는 부분 수정

 

[의사결정과정]

 

- 방안_1 친구요청 상태값 enum으로 컨트롤 되도록 수정

- 방안_2 친구 요청 상태값 코드로 구성된 별도 테이블 새로 구성하여 작업

 

[현 상황과 해당 방안 선택한 이유]

- 친구요청 상태값이 현재 String형태로 상태값 비교 및 체크를 하고 있으나, 이 부분은 상태값 같이 반영구적으로 진행되는 값들에 대해선 좋지 않은 방법으로 보임.

- 이를 바탕으로 1번과 2번의 2가지방법 중 1번이 적합하다고 생각했다.

- 2번은 상태값이 별도로 추가되거나 수정 삭제 같은 상황이 생길때 좋다고 할 수 있으나, 친구요청에서의 상태값은 대기 수락 거절로 진행이 되기때문에 1번 enum으로 컨트롤 되도록하고 테이블은 굳이 따로 빼지 않아도 되겠다라고 판단했다.

 

[2번의 좋은 활용 예시]

일정상태값)
- 회의, 휴가, 연차, 반차, 출장, 미팅

- 위와 같이 추가 및 수정 삭제가 될 수 있는 상태 값들 게다가 view에서 select박스로 관리하기 좋은 형태

 

3) 회고

문제1)  - 처음 프로젝트를 시작할때 jpa의 대해서 잘 알고있었다면 굳이 count함수를 위해서 nativeQuery를 활용하지 않고 진행이 가능했을텐데란 생각을했다. 쿼리를 직접 작성하게 되면서 Repository에서 코드가 길어졌었는데 해결방안들을 사용하여 코드개선을 진행해서 훨씬 코드가 보기 편해졌다. 또 한 굳이 쿼리가 바로 공개될 일이 없어서 보안적으로도 훨 나은 결과라고 생각을 했다.

 

문제2) - 상태값을 관리하는 별도의 테이블을 구성해보자란 생각을 했는데 친구요청상태값이 사실상 영구적인 상태라 문제는 없을 것이라고 생각했다. 백엔드에서만 구현되어 있는 기등들이다보니 한계점이 있는데 프론트엔드도 같이 구현이 되어 있는 상태라면 프론트엔드와 백엔드가 매끄럽게 이어지도록 데이터를 주고받는 방식이나 entity설계 등 더 꼼꼼하게 생각해야겠다고 느꼈다.(이부분은 어느 개발언어에서든 웹개발 프로젝트를 들어가게 된다면 고려해야하는 부분이라고 당연히 알고있다.) enum을 잘 활용해야겠다고 느꼈다. 위에서 말한것처럼 거의 영구적인 데이터이고, 상태값들이 String으로 관리되게 된다면 테스트나 추후 유지보수나 데이터 저장되는 부분이나 여러가지 측면에서 문제가 된다는 점을 깨달았다. 큰 틀로 보면 코드값과 enum과 고정적인 형태의 데이터를 좀 더 효율적으로 관리하는 방법으로 좋은 방법들이라고 느꼈다.