리팩토링

인프런의 Real my sql 강의를 참고하면서 프로젝트를 리팩토링한다. 우선, 이 타입들을 사용하면 문자열을 저장할 수 있게 된다. CHAR는 고정형, VARCHAR는 가변형, TEXT는 공통점 문자열 저장용 칼럼(가변형) 최대 저장 가능 문자 길이

스프링 카페를 할 때 처음 만든 테이블 도식도이다. 이에 대해 리뷰를 받은 것들을 확인해보자.comment 테이블을 보면 불필요하게 writer_id, writer_name 모두가 외래키 제약 조건이 걸려 있다. 외래키는 말 그대로 key이기 때문에 writer를 식별

2주차에서 pr을 보낼 때 여러 질문을 보냈다. 그 중 하나가클라이언트에서 받은 dto를 엔티티 객체로 변환할 때 어느 레벨에서 하는 것이 적합할까요? (service / controller)였다.저는 서비스 레이어에서 변환해주는걸 선호하는 편입니다! 저는 가능한 pr

다른 팀의 리뷰에 BigDecimal 이라고 자바에서 화폐단위를 나타낼때 주로 쓰는 타입이 있는데 Integer 보다 해당 타입을 쓰시는게 좋을거 같아요~왜 BigDecimal 을 쓰는지는 한번 공부해보셔도 좋습니다! 생각보다 현업에서 화폐 같은걸 다루다보면 반올림으로

다른 팀의 리뷰를 보던 중 해당 엔티티안에서만 사용할꺼면 private으로 변경하는게 좋은거 같아요. 근대 이거는 service layer에서도 사용될거라 별도 클래스로 하는게 더 괜찮은거 같습니다.이런 리뷰를 봤다.우리 팀도 이렇게 돼 있었는데이 enum 타입을 사용

호출 될 때마다 Random 인스턴스를 생성하는 코드인데 의도하신 부분일까요?이런 부분에 대해서는 앞으로 계속 주의하면 좋을 거 같다. 인스턴스를 미리 만들어서 사용하는 캐싱 작업은 필요한 곳에서 사용하기.서버에서 색상에 대한 유효성 검증(hex인지 여부 확인)을 해

여기는 @Transactional(readOnly = true) 가 빠져 있네요. 이런 경우 때문에 Query(조회성 메소드 만) / Command(CUD 성 메소드) 서비스를 분리해서 @transactional 을 달아주고는 합니다. 혹시, @Transactional

다른 팀의 리뷰에서 본 내용이다.현재 Accommodation 안에서 양방향 맵핑과 Cascade를 사용하여 Amenities와 Images를 한 번에 저장하고 있습니다.FK를 직접 가지고 있는 Amenity와 Images가 아닌, Accommodation을 통해 한

한 도메인의 서비스에서 이렇게 다른 도메인들의 DB에 접근해야 하는 일이 있을 때 어떻게 처리하는 것이 좋을지 항상 고민하게 되는 것 같습니다.지금처럼 다른 도메인의 레포지토리를 바로 참조하는 방식 → 다른 도메인의 레포지토리를 모두 가지고 있게 되면서 서비스가 의존하

Restcontroller와 ResponseEntity에 대해서 공부해보세요 라는 리뷰가 있었다. 평소에 두개를 같이 쓰던 입장에서 어떤 차이가 있는지 궁금했는데 라고 한다. Restcontroller가 ResponseBody와 controller 어노테이션을

airbnb 이면 외국 시간도 고려해야 되지 않을까요? KST 만 보는 것으로 합의되었다면 괜찮긴 합니다.라는 리뷰가 보여서 시간선에 대해서 공부해봤다.Java의 날짜, 시간에 대한 기본적인 정책기존 java의 날씨 api에는 여러 문제가 있었다고 한다.(Date, C

UUID는 B-tree의 인덱스 성능을 저하할 수 있다.ULID, UUID와 MySQL B-tree indexUUID는 random 성격의 id다. MYSQL에 PK로 넣을 때 성능에 저하를 줄 수 있다.B-tree index에서 B는 'Balance'를 뜻한다. 이

저는 영속성 레이어에는 validation 을 걸지 않는 편 입니다.코드에서는 걸더라도 결국 DDL 레벨에서는 안거는게 보통 입니다.마이그레이션 등의 어려움이 있기 때문입니다.영속성 레이어의 validation 에 의존하는 것 보다는 도메인 레이어의 validation

좋은 예외(Exception) 처리예외를 처리할 때는 복구가능한 것과 복구 불가능한 것을 분리해야 한다.보통, 시스템 외적인 요소로 발생하는 치명적이지 않은 오류다.사용자가 잘못된 전화번호를 입력했다면 이는 시스템을 멈춰야 할 정도의문제라고 할 수 없다.다시 입력하라는

IDENTITY 전략의 경우 JPA의 쓰기지연이 안될 수 있는데요. 이 부분 인지 하고 계신걸까요?모르셨다면 왜 쓰기지연이 안되는 상황이 있는지? 부터 접근을 해보시는 게 좋습니다. 자동증가 기본키가 맹목적으로 안좋다기보다는 상황에 따라 더 나은 선택지가 있는 거 같습

List 이라는 타입으로 바로 리턴해주는데요, dto 클래스로 한번 래핑해서 보내주면 어떨까요??DTO 응답 객체에만 컨트롤러가 의존하게 하고 List나 Double 같은 타입이 바로 노출되는것 대비해서 확장성, 캡슐화에도 좋고 스웨거 API 문서화를 할때도 좋습니다

프로젝트가 전체적으로 postFix로 Entity가 안붙어있는데, IssueEntity, LabelRefIdEntity와 같이 postfix로 ~Entity로 하면 계층 구분하는게 더 용이합니다.마치 RequestDto, ResponseDto를 보면 Presentati