TIL-230922('행동대장' 코드리팩토링 - 마이페이지(2))

📝오늘 공부한 것

• 실전프로젝트 - '행동대장' 코드리팩토링(마이페이지)

 

📌코드리팩토링 - 마이페이지 부분

 

⛔ 문제점 : 단일 책임 원칙 및 JWT 생성 시 고유한 값을 넣어주지 않음.

JWT 생성 시 닉네임을 이용하여 만들다 보니, 닉네임이 변경되면 원래 user가 가지고 있던 JWT 인증 정보와는 일치하지 않아 에러가 났다. 그래서 이 문제를 해결하기 위해 사용자의 닉네임이 변경될 때마다 새로운 access token과 refresh token을 발급하여 클라이언트로 전달하도록 처리하도록 리팩토링을 진행했었다.

 

https://yewon0309.tistory.com/entry/TIL-230831%ED%95%AD%ED%95%B499-%EC%8B%A4%EC%A0%84-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%ED%96%89%EB%8F%99%EB%8C%80%EC%9E%A521

TIL-230831(항해99 실전 프로젝트-행동대장(21))

 

SRP(Single Responsibility Principle) : 단일 책임 원칙
모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다.
                                                                                                                                                      -로버트 마틴

또한, updateNickname의 메서드를 보면 닉네임을 변경해 주는 역할뿐만 아니라, access token과 refresh token도 발급하는 역할을 하고 있다.

 

[updateNickname 메서드]

메서드명만 봤을 때 '닉네임을 변경해주는 메서드구나'하고 알아야 하는데, 토큰을 발급하는 기능까지 같이 만들어버린 것이다. 그래서 하나의 메서드에 2개의 책임을 갖게 되었다.

 

JWT를 생성하는데 들어가는 값이 고유한 값이 아닌 변경가능한 값을 넣어주어서 발생하는 문제들이었다.

 

[createToken 메서드]

[UserDetailsServiceImpl]

 

 

💯 해결

변경가능한 값인 nickname 대신 고유한 값인 user_id를 넣어주었다.

 

[createToken 메서드]

 

filter에서 인증처리와 인증 객체를 생성할 때 nickname 대신 userId를 사용하도록 변경하였다.

 

[JwtAuthorizationFilter]

이전에는 인증 객체를 생성할 때 UserDetailsService를 상속받은 userDetailsServiceImpl의 loadUserByNickname을 오버라이딩하여 사용하였다.

그런데 loadUserByUsername은 매개변수로 string을 받아햐 하는데, 나는 Long타입인 userId를 받아야 하는 상황이었다.

그래서 UserDetailsService를 상속받지 않고 loadByUserId라는 메서드를 새로 만들어 사용하였다.

 

[UserDetailsService]

마지막으로, service로직의 getNickname을 모두 getUserId로 변경해 주었다.

 

[UserService의 login메서드]

 

JWT에 들어가는 정보를 nickname이 아닌 userId로 변경을 하여 더 이상 닉네임을 바꿔도 토큰이 바뀌지 않아 새로운 토큰을 발급해 줄 필요가 없어졌다.

updateNickname에 있는 토큰을 보내주는 로직들을 모두 삭제!!!

 

[updateNickname 메서드]

이제는 드디어 updateNickname메서드가 닉네임을 변경하는 기능만 수행하게 되었다~!!!

 

---

⛔ 문제점 : Transactional 관리

불필요하게 Transaction을 적용하거나, 적용해야 할 곳에 적용하지 않은 경우가 있었다.

 

💯 해결

transaction에서 데이터를 읽기만 할 때 readOnly=true를 사용한다.

이 속성을 사용하면 읽기 작업에 대한 최적화를 수행할 수 있고, 영속성 컨텍스트가 자동으로 flush 되지 않으므로 예상하지 못했던 수정을 방지할 수 있다.

따라서 조회기능에 @Transactional(readOnly=true)를 사용하였다.

그리고 불필요하게 Transactional을 걸어준 곳에는 삭제를 하였다.

 

느낀 점🤔

오늘의 리팩토링으로 인해 updateNickname메서드가 닉네임을 변경해 주는 역할에만 집중하고, 단일 책임 원칙을 준수할 수 있게 되었다. 또한, JWT관련 문제도 해결하여 코드의 유지보수성이 향상되었다.