1번
•
우선 176-179줄이 이후로도 계속 반복되고 있습니다. 이를 content를 매개변수로 받아 PostReadResList를 반환하는 메서드로 분리하고, 따로 dto에 따라 post를 반환하는 메서드를 만들어서 중복을 최소화 하는 것이 좋을 것 같습니다. 제가 querydsl 에 대해서는 잘 몰라서 여기까지.. 못할 것 같습니다.
•
스위치 케이스 문을 쓴다면 개선된 switch 표현식을 써보시면 더욱 가독성 있습니다.
•
천천히 읽어 봤는데 제 기준에서는 괜찮은 것 같습니다. QPost.post를 import static 해주셔서 post만 쓰면 조금 더 깔끔해질 것 같습니다.
•
ALL 빼고 매개변수의 형태가 같으니, 이를 추상 메소드로 뽑아서 관리해보는건 어떨까요? 즉, switch문을 서비스단이 아닌 레포단에서 작성해서 분기시키면 어떨까라는 생각이 듭니다!
2번
•
POST맨으로 웹소켓연결이 확인이 안되는건 주소를 잘못 입력했을 가능성이 높아보입니다. ws://localhost:8080/ws 를 잘입력하셨는지 확인해 보시고 그래도 연결이 안된다면 securityconfig에서 /ws를 permitAll하고 테스트 해봐주시면 될 것같습니다. 그리고 stomp를 활용한 채팅기능테스트는 https://jxy.me/websocket-debug-tool/이 사이트를 통해서 실제로 채팅이 전송되는지 확인했습니다.
•
저희 같은 경우는 채팅이 대부분 프론트 쪽에서 이루어지다 보니 채팅 테스트 할 때 정말 간단한 페이지를 만들어서 테스트 했습니다.
페이지에 접속하게 되면 엔드포인트 주소로 웹소켓 연결 맺어주고 채팅이 제대로 가는지 확인하면서 테스트 했습니다.
•
혹시 프론트에서 SockJS를 사용하신 상태이신가요? 그렇다면, 다음과 같이 SockJS를 등록하는 코드를 추가해보시면 어떨까 싶어요!
@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint("/ws")
.setAllowedOriginPatterns("*");
.withSockJS(); //버전 낮은 브라우저에서도 적용 가능
}
Plain Text
복사
3번
•
맥락에 따라 코드를 공백 라인으로 나누면 더욱 가독성 좋을 것 같습니다.
•
빌더를 한 줄로 다 적기보다, 한 줄에 .메서드 하나씩 적어서 줄을 넘기면 더욱 가독성 좋을 것 같습니다.
•
System.out.println 보단 로그를 이용하면 디버깅하는데 더욱 좋을 것 같습니다(시간, 실행객체 확인 등등)
•
updateReviewByManners, updateReviewByTime 이런 식으로 나누고 ==1 보다는 빼주는 것이 그나마 깔끔해보이지 않을까 생각합니다. 고수님들을 통해 좋은 방법 찾으시길 바랍니다!
•
개인적으로, for문을 통해 데이터를 접근하기 보단 stream을 사용해보면 좀 더 깔끔해지지 않을까라는 생각이 듭니다!
튜터님
•
System.out.println을 사용한 코드가 보입니다. 실제 운영 환경에서는 로깅 라이브러리인 Slf4j를 사용하도록 하고 로그 level을 설정하여 꼭 필요한 로그들만 출력될 수 있도록 만드는것이 좋습니다.
•
3번 피드백의 조건문이 아주 길게 잡혀있는데 이러한 부분은 가독성을 매우 나쁘게 만들기 때문에 별도의 메서드로 추출하거나 조건문을 단순화할 수 있도록 만들어주시면 좋겠습니다.
