Conversation
기존에는 이메일만 일치하면 패스워드와 상관없이 로그인되었음 이를 수정했고, 추후 요청 바디로 전달된 패스워드를 암호화하여 이를 비교하는 기능도 구현할 예정임.
같으면 login하여 토큰 반환, 틀리면 status code 400과 함께 에러메시지 반환
MemberService.signUp() 메서드 내에서 builder를 이용해 createAt컬럼을 채우도록 했습니다.
Member.updatedAt에 대한 setter정의했고, password 업데이트 시 encoding하도록 수정했습니다. 또한 MemberController.updateMyPage() 메서드에서 MemberInfoDTO를 data로 응답하도록 수정했습니다.
당직, 연차 예외처리
Member엔티티 생성 및 수정 시 created_at, updated_at 갱신되도록 수정
설정한 default value가 스키마에는 적용되나 실제 값으로는 반영이 안되던 이슈가 있어 해당 필드를 Wrapper클래스로 수정했습니다.
|
안녕하세요. 다른 조는 연차, 당직 테이블 합쳐서 코드 작성했는데 7조도 저희 조 와 똑같이 연차, 당직 테이블을 나눠서 코드 작성해 주셔서 보기가 편했습니다.👍 특히 연차,당직 서비스에서 바로 에러 메시지를 작성해 주신 건 무엇이 잘못되었는지를 즉시 알 수 있으니깐 좋은 것 같습니다. 그러나 앞으로 프로젝트가 커지고 코드의 규모가 커진다면 일관성 유지가 필요하게 될 것 같은데 그때 중앙화된 에러 메시지를 이용하는 것도 방법일 것 같습니다!! 전체적으로 코드가 깔끔해서 잘 봤습니다👏🏻👏🏻👏🏻 |
| import java.time.LocalDateTime; | ||
|
|
||
| @Getter | ||
| public class DutyCreateReqDTO { |
There was a problem hiding this comment.
DutyCreateReqDTO와 DutyUpdateReqDTO 이 유사한 필드 구조를 갖고 있는데 혹시 두개로 나눈 이유가 있을까요?
leaveds5415
left a comment
There was a problem hiding this comment.
씨큐리티보다는 로직 관점에서 리뷰를 드렸어요.
- 팀의 전체적인 컨벤션을 맞추는 것
- 각 객체들이 필요한 계층 위치하고, 올바른 의존 방향을 갖는지
- 도메인 로직은 올바른 곳에 위치하는지
고민해보면 좋을 것 같습니다 🙇
수고하셨어요 👍
| @@ -18,8 +16,25 @@ public AnnualController(AnnualService annualService) { | |||
| this.annualService = annualService; | |||
| } | |||
There was a problem hiding this comment.
Nit:
의존성 주입을 롬복으로 간단히 할건지, 생성자로 주입을 명시적으로 보여줄건지 통일이 되면 좋을 것 같습니다. 👍
| import lombok.Getter; | ||
|
|
||
| @Getter | ||
| public class AnnualActionReqDTO extends AnnualUpdateReqDTO{ |
There was a problem hiding this comment.
중복을 줄이려는 의도인 것으로 이해했어요.
그렇지만, api 에서 RequestBody 를 받기위해서 생성한 객체 ReqDto 와 Annual 을 update 하기 위해 다루는 객체 간에 의존성을 갖게 두는 것은 다시 한 번 생각해보면 좋을 것 같습니다 🙇
또한, Annual 이라는 도메인 객체가 update 하기 위해 받는 updateReqDto 의 네이밍도 고려해보면 좋을 것 같습니다 🙇
| @Getter | ||
| public class AnnualCreateReqDTO { | ||
| private LocalDate startDate; | ||
| private LocalDate endDate; | ||
| private String summary; | ||
| private String reason; | ||
| } No newline at end of file |
| public class AnnualPageListDTO { | ||
| private List<AnnualPageDTO> annuals; | ||
| } No newline at end of file |
There was a problem hiding this comment.
컬렉션을 객체로 Wrapping 하여 Response 만든 것 👍
| AnnualPageListDTO annualPageListDTO = new AnnualPageListDTO(); | ||
| annualPageListDTO.setAnnuals(pageList); | ||
| return annualPageListDTO; | ||
| } |
There was a problem hiding this comment.
생성자나 정적 팩토리 메소드를 사용하여 생성하는 것도 고려해보면 좋을 것 같습니다.
| return APIDataResponse.empty(HttpStatus.OK, memberService.isDuplicateEmail(email) ? | ||
| "중복된 이메일입니다." : | ||
| "사용가능한 이메일입니다."); |
There was a problem hiding this comment.
삼항연산자를 사용하는 것보다는 로직으로 구성해두는 것도 고려해보면 좋을 것 같습니다
|
|
||
| public boolean isTelUpdated() { | ||
| return tel != null && !tel.trim().isEmpty(); | ||
| } | ||
|
|
||
| public boolean isPasswordUpdated() { | ||
| return password != null && !password.trim().isEmpty(); | ||
| } |
There was a problem hiding this comment.
이 부분도 로직에 해당하는 것 같아요.
Dto 내부에서 처리하는게 맞는지 생각해보면 좋을 것 같습니다.
| return dayOfWeek != DayOfWeek.SATURDAY && dayOfWeek != DayOfWeek.SUNDAY; | ||
| }).count(); | ||
|
|
||
| return (int) numOfDaysWithoutWeekends; |
There was a problem hiding this comment.
날짜가 들어가는 값이니 확률은 극히 적겠지만, long 을 int 로 캐스팅하는 것에 대해서 고민해보면 좋을 것 같습니다
| @AllArgsConstructor | ||
| @NoArgsConstructor | ||
| @Builder |
There was a problem hiding this comment.
@entity 로 다루고 있는 JPA Entity에 @AllArgsConstructor 과 @builder 를 한 번에 사용하는 것 vs id 가 빠진 생성자를 직접 만들고 @builder 사용에 어떤 차이가 있는지 생각해보시면 좋을 것 같아요
| for (Annual annual : annuals) { | ||
| if ((tempStartDate.isEqual(annual.getStartDate()) || tempStartDate.isAfter(annual.getStartDate())) && | ||
| (tempStartDate.isEqual(annual.getEndDate()) || tempStartDate.isBefore(annual.getEndDate()))) { | ||
| return true; | ||
| } | ||
| if ((tempEndDate.isEqual(annual.getStartDate()) || tempEndDate.isAfter(annual.getStartDate())) && | ||
| (tempEndDate.isEqual(annual.getEndDate()) || tempEndDate.isBefore(annual.getEndDate()))) { | ||
| return true; | ||
| } | ||
| if ((annual.getStartDate().isEqual(tempStartDate) || annual.getStartDate().isAfter(tempStartDate)) && | ||
| (annual.getStartDate().isEqual(tempEndDate) || annual.getStartDate().isBefore(tempEndDate))) { | ||
| return true; | ||
| } | ||
| if ((annual.getEndDate().isEqual(tempStartDate) || annual.getEndDate().isAfter(tempStartDate)) && | ||
| (annual.getEndDate().isEqual(tempEndDate) || annual.getEndDate().isBefore(tempEndDate))) { | ||
| return true; | ||
| } | ||
| } | ||
| return false; |
There was a problem hiding this comment.
이런 로직들은 작은 메소드 단위로 분해해볼 수 있을 것 같아요
No description provided.