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(); //버전 낮은 브라우저에서도 적용 가능
  }
  
  

3번

• 맥락에 따라 코드를 공백 라인으로 나누면 더욱 가독성 좋을 것 같습니다.
• 빌더를 한 줄로 다 적기보다, 한 줄에 .메서드 하나씩 적어서 줄을 넘기면 더욱 가독성 좋을 것 같습니다.
• System.out.println 보단 로그를 이용하면 디버깅하는데 더욱 좋을 것 같습니다(시간, 실행객체 확인 등등)
• updateReviewByManners, updateReviewByTime 이런 식으로 나누고 ==1 보다는 빼주는 것이 그나마 깔끔해보이지 않을까 생각합니다. 고수님들을 통해 좋은 방법 찾으시길 바랍니다!
• 개인적으로, for문을 통해 데이터를 접근하기 보단 stream을 사용해보면 좀 더 깔끔해지지 않을까라는 생각이 듭니다!

튜터님

• System.out.println을 사용한 코드가 보입니다. 실제 운영 환경에서는 로깅 라이브러리인 Slf4j를 사용하도록 하고 로그 level을 설정하여 꼭 필요한 로그들만 출력될 수 있도록 만드는것이 좋습니다.