Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEAT] 솝트 로그 API 개발 - #437 #459

Open
wants to merge 7 commits into
base: dev
Choose a base branch
from
Open

[FEAT] 솝트 로그 API 개발 - #437 #459

wants to merge 7 commits into from

Conversation

rlarlgnszx
Copy link
Contributor

📝 PR Summary

🌴 Works

  • ] 솝트 로그 API 개발

🌱 Related Issue

closed #437

🌵 PR 참고사항

image

@rlarlgnszx rlarlgnszx self-assigned this Nov 22, 2024
Copy link

height bot commented Nov 22, 2024

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

Copy link
Member

@kseysh kseysh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API 명세서와 응답 값이 다른 것 같아 코멘트 남겼습니다 확인부탁드려요!

Comment on lines +5 to +9
import lombok.AccessLevel;
import lombok.Builder;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.ToString;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P5. 기존에 사용하던 와일드 카드로 변경하는 것이 가독성에 좋을 것 같아요

@Schema(description = "파트")
private PlaygroundPart part;
@Schema(description = "콕찌르기 횟수")
private String pokeCount;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2. 콕 찌르기, 솝활동, 솝탬프 모두 뒤에 ~등, ~회, LV등을 붙이는 것 클라와 상의 후에 모두 붙이거나, 모두 붙이지 않거나 하는 것이 좋을 것 같아요.
또한 현재 API 명세서에 정의되어 있는 값들과 응답값이 많이 다른 것 같아요 API 명세 수정 혹은 응답 값 수정 부탁드립니다.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

넵 수정했습니다!

Comment on lines 131 to 141
public static SoptLog of(final String userName, final String profileImage, final PlaygroundPart part, final String pokeCount, final String soptampRank, final String soptLevel, final String profileMessage) {
return SoptLog.builder()
.userName(userName)
.profileImage(profileImage)
.part(part)
.pokeCount(pokeCount)
.soptampRank(soptampRank)
.soptLevel(soptLevel)
.profileMessage(profileMessage)
.build();
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P4. 매개변수가 많은 생성자는 builder 메서드를 활용하는 것이 더 유용할 것 같습니다.
soptampRank, soptLevel, profileMessage가 모두 String을 사용하므로 혼동의 가능성이 있어 builder로 명확히 표현해주는 것이 좋을 것 같아요
+ 또한 사용되지 않는 메서드라면 삭제하는 것이 좋을 것 같아요

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

사용하지 않는 메소드라 제거했습니다

Comment on lines 81 to 85
int soptLevel = authFacade.getUserSoptLevel(user);
Long pokeCount = pokeFacade.getUserPokeCount(user.getId());
Long soptampRank = rankFacade.findUserRank(user.getId());
PlaygroundProfile playgroundProfile = authFacade.getUserDetails(user);
return ResponseEntity.ok(SoptLog.of(soptLevel, pokeCount, soptampRank, playgroundProfile));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P5. Controller에 비즈니스 로직을 포함하는 것은 @transactional을 사용하기 어려워 Controller에서의 비즈니스 로직 작성을 최대한 피하고 있었는데 기훈님 생각도 궁금합니다!
제 생각에는 전부 다 굳이 facade에 들어가지 않아도 되는 메서드 같아서 차라리 솝트로그를 관리하는 새로운 facade를 만들고 그 facade에 playgroundAuthService, pokeService, RankFacade(RankService로 변환하는게 좋을 것 같네요)를 사용하는 것이 �좋지 않을까라는 생각이 들어요

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

음 제 생각에는 이 코드는 비즈니스 로직보다는, 각계층별로 데이터를 조회하고 매핑하여 반환하는 역할을 수행하기 때문에 비즈니스 로직보다는 , 응답 매핑 역할을 하는 어플리케이션 코드측에 속한다고 생각합니다!
그리고 트랜잭션을 사용함에 있는 부분을 생각해보면 롤백이 일어나는 부분이 필요하지 않다고 생각했고 오히려 새로운 facade를 만든다면 그안에 또다른 서비스를 사용한다면 각 service는 이제 더많은 의존관계가 생긴다고 하여 이렇게 작성했습니다!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

흠 그렇군요! 기훈님 의견 들어보고 고민해보는 것도 재밌네용

저는 나중에 반환해야 할 api가 변경될 때도 고려를 했어요. 솝탬프는 이전 기수에서도 사라지려고 했었던 피쳐이기도 하고, 새로운 피쳐가 생기면 새로운 피쳐를 솝트로그에 나타내도록 할 수도 있을 것 같아서요
그때마다 controller를 변경하는 것은 맞지 않다고 생각하고 그래서 저는 이것도 비즈니스 로직이라 봤습니다!
따라서 새로운 facade를 이용해 솝트 로그에 대한 책임을 갖는 객체를 하나 더 만든다면 솝트 로그 변경에 있어 다른 객체에 대한 영향이 적을 것으로 판단했어요.
또한 각 service는 어차피 controller에 의존관계가 생기나, facade에 의존 관계가 생기나의 차이라 크게 문제 없을 것으로 판단했습니다!

또한 Transactional(readonly=true)는 롤백 이후에도 변경감지를 위한 스냅샷을 보관하지 않아 메모리상 이점이 있다는 생각을 했는데, 그렇다면 DB 커넥션을 너무 오래 잡고 있는 거려나 생각이 들어서 Transactional에 대해서는 그냥 의견이었습니다!

Comment on lines +30 to +34
.map(user -> new AbstractMap.SimpleEntry<>(rankPoint.getAndIncrement(), user))
.filter(entry -> entry.getValue().getId().equals(userId))
.map(AbstractMap.SimpleEntry::getKey)
.findFirst()
.orElseThrow(() -> new IllegalArgumentException("User not found")));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2. 전부를 map으로 변환하고 찾는 것이 아닌 totalPoint를 이용해 sort된 유저를 1등부터 확인하며 userId와 일치하는 유저를 찾아 반환하는 것이 더 빠르게 순위를 반환하는 방법일 것 같아요

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

오 좋은 방법이네요 감사합니다!

return playgroundAuthService.getUserSoptLevel(user);
}

public PlaygroundProfile getUserDetails(User user) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P4. user를 매개변수로 전달하는 것이 아닌 필요한 playgroundToken만 전달하는 것이 좋을 것 같아요

Copy link
Member

@kseysh kseysh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

제 생각에는 솝트로그 부분을 아래 응답 값처럼 한다면 이후에 변경에 용이하고, 성능 개선에 이점이 있을 것으로 생각되어요
물론 바쁘시거나 due date가 다가온다면... 넘어가도 되지만 의견이 생각나서 남겨봅니다!

이 응답 값을 사용했을 때의 장점은

  • 유저 이름, 파트, 이미지를 반환하는 api를 따로 빼서 클라가 따로 캐싱할 수 있게 하여 성능 개선을 할 여지를 줄 수 있다 (현재는 변경되는 값과 함께 반환되어 캐싱할 수 없음)
  • 이후에 ui 변경시에 클라가 아닌 서버에서 쉽게 ui 변경을 시도할 수 있다.
  • isActive 값을 이용해 클라가 분기처리를 하지 않고 서버에서 주는 값을 그대로 사용할 수 있다.
  • 각 객체에서 반환한 값으로 리스트를 만들어 반환할 수 있다.
{
	[
		"name":"솝레벨"
		"icon":"~~"
		"description":"Lv.6"
	],
	[
		"name":"콕찌르기"
		"icon":"~~"
		"description":"208회"
	],
	[
		"name":"솝트와"
		"icon":"~~"
		"description":"33개월"
	]
}

Comment on lines +91 to +101
public Long getDuration(Long myGeneration, Long currentGeneration) {
long monthsBetweenGenerations = (currentGeneration - myGeneration) * 6;
LocalDate now = LocalDate.now();
int currentMonth = now.getMonthValue();
int startMonth = (currentGeneration % 2 == 0) ? 3 : 9;
int monthsSinceStart = currentMonth - startMonth;
if (monthsSinceStart < 0) {
monthsSinceStart += 12;
}
return monthsBetweenGenerations + monthsSinceStart;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2. 현재 홈화면에서 사용되는 ActivityDurationCalculator 사용하면 될 것 같습니다!

Comment on lines +89 to +90
Long soptampRank = null;
Long soptDuring = null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2. Long 값을 null로 전달하는 것보다 isActive 값에 따라서 ResponseEntity를 return하는 것이 좋아보여요.
팩토리 메서드 패턴을 이용해서 클라에 전달할 때만 null로 전달하는 것이 좋을 것 같아요!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEAT] 플레이그라운드 프로필정보 확인 기능
2 participants