리팩토링

[Hank-Choi]

코드가 점점 섞여서 벌써 스타일이 뒤죽박죽 시작한 느낌

한번 다같이 코드리뷰하는거 어떤가요
PR에서 다 얘기했어야 하는데 못보고 막상 클론받고 보니까 마음에 안드는 부분들이 좀 있는듯?

한번 회의 잡았으면 함

@Jhvictor4
@subeenpark-io
@davin111

[Hank-Choi]

참고로 이 이슈 만든 이유는 내 쓰레기같은 좌석 알림 배치 코드때문이기도 함
돌아가게만 짜서

[davin111]

@Hank-Choi 좋아요~

[Hank-Choi]

WIP
반박 환영

• 객체 변환 로직
  • Entity 객체는 의존성 거의 없도록 구성되면 좋을 듯
    • Dto -> Entity : toEntity
      • 별로라면 Entity의 확장함수 사용 but 위치는 Entity 파일이 아닌 Dto 파일에 있도록
    • Entity -> Dto: Dto 생성자 혹은 from~~같은 static 메소드 사용
    • Entity 이외에도 핵심 객체가 의존성을 갖지 않도록 구성
      • legacy 스펙도 최대한 객체 내에 없도록 분리 했으면 좋겠음 (같은 파일에도 위치하지 않으면 좋겠음)
      • ex)

        snutt-timetable/core/src/main/kotlin/lectures/utils/ClassTimeUtils.kt

        Lines 36 to 39 in a49de1f

        	val ClassPlaceAndTime.startPeriod: Double
        	get() = floor((startMinute - 8 * 60).toDouble() / 60 * 2) / 2
        	val ClassPlaceAndTime.endPeriod: Double
        	get() = ceil((endMinute - 8 * 60).toDouble() / 60 * 2) / 2

  • dto 전환은 controller 단에서 사용했으면 합니다.
    • service 단에서 중요도가 낮은 response dto로의 전환 혹은 request dto 그대로 파라미터로 받지 않으면 좋겠음
    • 확장성 높은 함수만 만들기 converting이 서비스단에서 필요하다면 꼭 범용성 높은 함수와 같이 작성
• 명명 규칙 (legacy 제외)
  • parameter: camel
  • api request, response: camel
  • api path: kebab
  • DB
    • collection명: camel
    • field: camel

[davin111]

db entity 를 클라에 그대로 반환하지 않는다.
log(not logger)로 이름 짓는다.