[♻️ refactor/#114]: signIn 메서드 리팩토링 및 코드 개선

[jsoonworld]

📄 Work Description

• signIn 메서드 내 여러 책임을 분리하여 가독성과 재사용성을 향상시켰습니다.
• 기존의 조건문을 Optional과 람다 표현식을 활용하여 간결하게 개선했습니다.

⚙️ ISSUE

• closed [♻️ refactor] 소셜 로그인 > 로그인 signIn 메서드 리팩토링 및 코드 개선 #114

📷 Screenshot

Swagger 200

💬 To Reviewers

이전 PR에서 의견이 나왔었는데요. private 메서드에 update 로직이 담겨 있으니 transcation을 붙여주는 게 낫다는 의견이 있었거든요, 제 생각에는 private 메서드를 사용하는 메서드에서 transaction을 사용하니, 중복을 제거하고자 붙이지 않아도 문제 없다는 생각이었습니다. 그 메서드를 다르 곳에서 사용하는 것이 아니기 때문에요. 그러나 메서드를 불러서 사용할 수 있다는 문제도 존재합니다. 어떻게 생각하시나요!?

[junggyo1020]

현재 PR에서 적용된 방식은 제가 이해하기에 signIn 메서드 자체에 @transactional을 적용하여, 메서드 내의 private 메서드들에 대해서는 별도의 transaction 관리를 하지 않았다는 것으로 이해했는데요!

다만, private 메서드에 @transactional을 붙이지 않은 이유는 메서드가 다른 곳에서 사용되지 않을 것이라고 가정하셨기 때문인데, 확실하게 메서드가 사용되지 않을 것이라 이야기 하기는 힘듭니다. 사실 만약 이 메서드들이 다른 곳에서 사용될 가능성이 있다면, transaction 처리 없이 호출되어 예기치 않은 버그가 발생할 수 있기 때문에 재사용성을 염두해 여러 대안을 생각해보면 좋을 것 같다는 생각입니다.

이 문제를 해결하기 위해,

첫번째로 @transactional을 반드시 필요한 곳에만 적용하고,
두번째로 private 메서드가 다른 곳에서 호출될 가능성을 낮추기 위해 메서드의 가시성을 더욱 제한하거나,
마지막으로 호출되는 곳에서 반드시 트랜잭션이 적용되도록 코드를 수정하는 방법이 있을 것 같습니다.

전반적으로 Optional과 람다 표현식으로 대체함으로써 불필요한 중복을 제거한 부분의 경우 유지보수의 측면에서 좋은 리펙토링이였다고 생각이 드네요!! 고생하셨습니다:)