2021년 9월 - 12월까지 시작한 세종 코딩 헬퍼 프로젝트를 리펙토링 하려고 한다.그때 당시에 Infra 및 백엔드 파트를 담당했는데 기술을 적용할 때 성능은 생각하지 않고 했기에,,아쉬움이 많은 프로젝트다. 견문을 쌓고 돌아온 지금, 해당 프로젝트를 보고 리펙토링
우선적으로 유저 Entity를 리펙토링 해보겠다.위 코드는 리펙토링 전 유저 Entity 코드이다.스프링 시큐리티에서 사용자 정보를 불러오기 위해 UserDetails를 상속 받았다.의문점이 든다. 왜 Entity에 UserDetails의 구현체를 만들었는지?→ Use
구글 stmp 서비스 유료화→ 네이버 stmp 서비스로 변경기존 코드변경 코드자세한 코드는 깃허브 참고하세요.여기서 에러날 부분이면javaMailService.send(h.getMimeMessage());이 부분이다. 그래서 try catch로 감싸준다음 에러를 만들어
기존 방법 : Session 이용. HttpSession을 여러 개 생성해서 이용해서 이메일을 검증했다.문제점 : Key 값 중복 위험이 있음.해결 방법 : Key, Value값의 맵을 사용하는 Redis를 이용한다.이점 : 캐시 서버이기 때문에 빠름. DB의 부하를
테스트 코드가 없어서 리펙토링을 해도 비효율적으로 검증을 해야 한다.요청 바디 값이 DTO가 아닌 map으로 정의되어 있어서 어떤 값을 줘야할 지 직관적으로 알 수 없다.return 값으로 String만 넘겨주기 때문에 클라이언트가 불친절하다고 느낄 수 있다.컨트롤러