공부한 내용
Stream VS For
리스트 형태로 된 response DTO를 생성할 때 어떤 로직에선 stream을 썼고, 어떤 로직에선 for문을 썼다. 이 부분이 아띠즈 플젝을 하면서 부터 궁금했다. 하나로 통일하면 안되는지!!
우선 플젝에서 썼던 코드들로 예시를 들어보겠다.
•
stream
@Transactional(readOnly = true)
public List<BeachMarkerResponse> findBeachMarkers() {
List<Beach> findBeachList = beachRepository.findAll();
List<BeachMarkerResponse> responseList = findBeachList.stream()
.map(m -> BeachMarkerResponse.builder()
.id(m.getId())
.lat(String.valueOf(m.getLat()))
.lng(String.valueOf(m.getLng()))
.image(getRecordMemberImage(m))
.build())
.collect(Collectors.toList());
return responseList;
}
Java
복사
@Transactional(readOnly = true)
public ArtistDetailResponse getArtistDetail(Long loginMemberId, Long artistId) {
Member member = memberRepository.findById(loginMemberId)
.orElseThrow(() -> new CustomException(ErrorCode.NOT_FOUND_MEMBER));
Member artist = memberRepository.findById(artistId)
.orElseThrow(() -> new CustomException(ErrorCode.NOT_FOUND_ARTIST));
List<ArtWork> artWorkList = artWorkRepository.findArtWorkByMember(artist);
return ArtistDetailResponse.builder()
.pick(memberPreferredArtistRepository.existsByMemberAndArtist(member, artist))
.member(ArtistDetailResponse.MemberDto.from(artist, awsStorageUrl))
.artworks(artWorkList.stream()
.map(m -> ArtistDetailResponse.ArtWorkDto.from(m, awsStorageUrl))
.collect(Collectors.toList()))
.build();
}
Java
복사
•
for
public List<RecordResponse> getRecordList(Long memberId) {
List<RecordResponse> recordResponseList = new ArrayList<>();
List<Record> recordList = recordRepository.findAllByMemberId(memberId);
for (Record record: recordList){
String beforeImageUrl = imageService.processImage(record.getBeforeImage());
String afterImageUrl = imageService.processImage(record.getAfterImage());
RecordResponse recordResponse = RecordResponse.builder()
.recordId(record.getId())
.beachId(record.getBeach().getId())
.time(record.getDuration())
.date(record.getCreatedDate())
.range(record.getDistance())
.beforeImage(beforeImageUrl)
.afterImage(afterImageUrl)
.build();
recordResponseList.add(recordResponse);
}
return recordResponseList;
}
Java
복사
검색해보고 알게된 사실은,, for문이 성능이 더 좋단 것이었다! 충격,,
그러면 우리는 왜 Stream문을 썼던 것일까,,,
바로, Stream문이 더 가독성이 좋기 때문이라는데 사실 난 크게 공감하지 못했다,,,
for문이 훨씬 익숙하고 Stream은 덜 익숙했기 때문이었다.
그래서 프로젝트 전체에서 Stream을 쓰지 말까 잠시 고민했다,,,
하지만 이 역시 많은 사람들이 Stream을 쓰는 이유가 있지 않을까 싶어 좀 더 찾아봤다.
아래 블로그 글을 보고 가독성 측면에서 Stream이 더 좋단 말을 단번에 이해할 수 있었다.
이중 for문으로 가니 확실히 Stream이 짧은 걸 확인할 수 있었기 때문이다.
결론적으로 팀원분과 Stream을 default로 쓰고, 간혹 Stream으로 해결되지 않는 것들(예를 들면 반복문 중간에 추가적인 작업들을 해줘야 하는 것들)만 For문을 사용하기로 결정했다.
하루 정리
TIL 작성하기
20시-21시 Atties 백엔드 회의
정정서 내기,, (정정 성공!)
22시-24시 BeachCombine 코어타임
이번주 목요일은 개강이다,,, 개강 목표는 매일 TIL 작성하기,, 학교에서 배운 내용으로도 좋음!
배운 내용 뿐만 아니라 할 일 정리도 할 겸 TIL 작성은 좋은 거 같다.
2년째 아래 처럼 매일 매일을 엑셀에다가 할 일을 정리해왔는데,, 이번 학기엔 TIL에 정리해봐야겠다!
사실 이전부터 TIL을 매번 써야지 써야지 하고서 안 쓰고 있었다.
가장 큰 비중을 차지했던 이유는 그냥 포스팅을 하는 게 낫지 않을까 하는 생각 때문이었다.
고런 생각에 TIL을 잠시 잊고 살았다,,,
그러던 내게 팀원분이 혹시 TIL을 쓰냐고 여쭤보셨는데
곰곰히 생각해보니 플젝을 하면서 함께 의논하며 배워나간 부분들을
정리하지 않으면 너무 아까울 거 같단 생각에 가볍게 TIL을 써보기로 결심했다.
막상 써보니 포스팅은 쓰다 보면 약간 부담이 가는 데 반해
가볍게 쓸 수 있는 TIL만의 매력을 느낄 수 있었다.
앞으로 잊지 않고 매일 써보려 도전해 보아야겠다. 개강 목표로,,
(아무래도 포스팅은 나만의 생각을 바탕으로 정리해야 한단 생각에 쓰다 보면 추가되는 내용들이 많아 쓰는 데 오래 걸리는 편이다,,, 뭔가 처음 보는 사람이 내 글을 보고 배울 수 있게 써야 한다는 강박이 든다,, 선생님 하던 버릇 어디 안 가는,,
)
)(TIL은 내 생각을 넣는 건 마찬가지이지만 막 보기 좋게 정리하고, 총 정리 느낌으로 정리할 필요 없이 짧게 짧게 쓸 수 있어, 그리고 나만 알아볼 수 있게 써도 된단 마음으로 일기장처럼 부담 없이 쓸 수 있어 좋은 거 같다!)