Refactor/#123 성능 최적화 - .stream() 제거 #124
Conversation
- 최적화를 위해 사용하지 않는 클래스에 대해 Deprecated 처리를 진행했습니다. - 이에 따른 로직 수정을 진행했습니다.
- .stream()을 사용하지 않는 방식으로 리팩토링
|
Risk Level 2 - /home/runner/work/Team5-Guys/Team5-Guys/logbat/src/main/java/info/logbat/domain/log/presentation/validation/ValidLogRequests.java Similar to LogRequestsValidator, marking this annotation as @deprecated is good. Ensure that the deprecation message is clear about the alternative approach. Risk Level 2 - /home/runner/work/Team5-Guys/Team5-Guys/logbat/src/main/java/info/logbat/domain/log/presentation/validation/LogRequestsValidator.java Marking the class as @deprecated is clear, but ensure that there is a plan for its removal or replacement. Consider adding a comment on what should be used instead. Risk Level 2 - /home/runner/work/Team5-Guys/Team5-Guys/logbat/src/main/java/info/logbat/domain/log/application/LogService.java The addition of error handling in the saveLogs method is a good practice, but consider logging the exception message more clearly. Instead of just logging the request, include the appId for better traceability. Example: 🛠️🔧📜 Powered by Code Review GPT |
|
|
||
| @RequestBody @Valid List<CreateLogRequest> requests) { | ||
| logService.saveLogs(appKey, requests); |
There was a problem hiding this comment.
Validation이 일부만 적용되어
중간에 잘못된 요청이 오는 경우 정상적인 요청까지 실패하게 될 것 같아요
어떻게 하는 것이 좋을까요?
There was a problem hiding this comment.
아예 Validate를 진행하지 않고 서비스 레이어에서 처리하는 방식은 어떨까요?
| logRepository.saveAll(requests.stream() | ||
| .map(request -> request.toEntity(appId)) | ||
| .toList()); | ||
| requests.forEach(request -> logRepository.save(request.toEntity(appId))); |
There was a problem hiding this comment.
forEach를 메서드로 돌리지 않고, 예외가 발생한 request는 내부적으로 무시하는 로직으로 가면 더 좋을 것 같습니다!
There was a problem hiding this comment.
예외가 발생한 request를 무시하는 로직을 적용한다면 다시 .stream()이 도입될 것 같은데 어떻게 생각하시나요?!
There was a problem hiding this comment.
단순 반복문만으로 처리하면 어떨까요? stream을 쓰면 좋겠지만 저희와 같은 상황에서는 어쩔 수 없으니,,
There was a problem hiding this comment.
지금,.save() 할때마다 LinkedBlockingQueue 에 삽입되는거라 비효율적으로 느껴집니다!!!
차라리 최적화 하기로 한거, JPA 도 안쓰는데 domain 객체를 컨트롤러로부터 직접 받는걸로하죠.
그렇게 할 경우 domain 객체를 생성할때 검증 로직도 포함되어 중복 검증을 막을 수 있겠다는 생각이 들어요.
제가 지금 domain 객체로만 해서 로직을 한번 작성해 볼테니 피드백 한번 부탁드리겠습니다!
- List를 생성해서 repository로 전달 - BlockingQueue이기 때문에 접근 횟수를 줄임
- 린트 수정
| .map(request -> request.toEntity(appId)) | ||
| .toList()); | ||
| List<Log> logs = new ArrayList<>(requests.size()); | ||
| requests.forEach(request -> logs.add(request.toEntity(appId))); |
There was a problem hiding this comment.
내부에서 예외가 발생할 경우 add하지 않고 무시하는 로직이 필요합니다!!
* chore: 사용하지 않는 클래스 Deprecated 처리 - 최적화를 위해 사용하지 않는 클래스에 대해 Deprecated 처리를 진행했습니다. - 이에 따른 로직 수정을 진행했습니다. * refactor: 저장 로직 변경 - .stream()을 사용하지 않는 방식으로 리팩토링 * refactor: List를 생성로직 추가 - List를 생성해서 repository로 전달 - BlockingQueue이기 때문에 접근 횟수를 줄임 * refactor: Log data는 비어있을 수 있다 * refactor: Controller 빈 배열 검사 추가 * test: 미사용 테스트 제거 * style: LogController - 린트 수정 * fix: 형식에 맞는 값을 제거하고 배열 저장 --------- Co-authored-by: luizy <[email protected]>
🚀 작업 내용
📸 이슈 번호