상품 주문 관련 테스트 코드를 돌리고 있는데 에러가 발생했다. id to load is required for loading; nested exception is java.lang.IllegalArgumentException: id to load is required for loading org.springframework.dao.InvalidDataAccessApiUsageException: id to load is required for loading; nested exception is java.lang.IllegalArgumentException 에러 문구를 읽어보니 id값에 문제가 있는 것 같았다. 에러가 발생한 위치를 확인해 보니 엔티티 매니저에서 아이템을 꺼내올 때 발생하는 문제였다. 에러 ..
인프런 김영한 선생님 를 보고 정리한 내용입니다. 📍 엔티티에는 가급적 Setter를 사용하지 말자 Setter를 열어두면 변경 포인트가 너무 많아져 유지보수가 어렵다. 📍 모든 연관관계는 지연로딩으로 설정하자 즉시로딩(EAGER)은 예측이 어렵고 어떤 SQL이 실행될지 추적하기 어렵다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다. (뜬금없는 의견이지만 N+1보단 1+N이 맞는 것 같다.) 실무에서 모든 연관관계는 지연로딩(LAZY)으로 설정해야 한다. 연관된 엔티티를 함께 조회해야 한다면, fetch join 또는 엔티티 그래프 기능을 사용한다. OneToOne, ManyToOne 관계는 디폴트값이 즉시로딩이므로 직접 지연로딩으로 설정해야 한다. ..
컨트롤러에서 요청과 응답을 관리하도록 구현하다 보니 계층 구조에 대해 궁금해졌다. 그 중 3-Tier를 알게 되었는데, 중요한 내용을 많이 담고 있어 정리하고자 한다. 3-Tier Architecture 어떠한 플랫폼을 클라이언트 계층, 애플리케이션 계층, 데이터 계층으로 나누어 별도의 장치에 구축 및 운영하는 형태 3-Tier 구성 서버 1. Presentation Tier 사용자가 직접 마주하게 되는 계층이다. 사용자 인터페이스를 지원하며 프론트엔드라고도 부른다. 웹 서버가 대표적인 예시이다. 2. Application Tier 들어오는 요청을 어떠한 규칙을 기준으로 처리하고 가공하는 계층이다. 데이터 계층에 업무를 넘기거나 참조하는 기능도 병행한다. 서버처럼 동작(응답)하고, 클라이언트처럼 행동(요..
클린코드 13장에서는 동시성을 아주 가볍게 다루고 있다. 더 자세한 내용은 뒤쪽 동시성II 또는 관련된 서적을 읽는 게 좋을 것 같다. 객체는 처리의 추상화다. 스레드는 일정의 추상화다. - 제임스 O. 코플리엔 동시성이 필요한 이유 동시성은 결합을 없애는 전략이다. 무엇과 언제를 분리하는 전략이다. 응답 시간과 작업 처리량 개선이라는 요구사항으로 인해 직접적인 동시성 구현이 불가피하다. 하지만 동시성은 다소 부하를 유발한다. 동시성은 복잡하다. 일반적으로 동시성 버그는 재현하기 어렵다. 일회성 문제로 여겨 무시하기 쉽다. 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다. 동시성 방어 원칙 동시성 코드는 다른 코드와 분리하라 자료 범위를 제한하라 (코드 내 임계영역을 synchronized ..
창발적 설계로 깔끔한 코드를 구현하자 모든 테스트를 실행한다. 리팩터링 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 1. 모든 테스트를 실행하라 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 테스트가 불가능한 시스템은 검증도 불가능하다. 검증이 불가능한 시스템은 절대 출시하면 안 된다. 즉, 테스트 케이스를 작성하면 설계 품질이 높아진다. 2. 리팩터링 코드를 정리하면서 시스템이 깨질까 걱정팔 필요가 없다. 테스트 케이스가 있기 때문이다. 코드를 점진적으로 고쳐나간다. 응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 함수와 클래스 크기를 줄이는 등 다양한 기법을 동원한다. 3. 중복을 없애라 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻한다. 공..
"복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다." - Ray Ozzie, 마이크로포스트 최고 기술 책임자 시스템 제작과 시스템 사용을 분리하라 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다. 1. Main 분리 생성과 관련된 코드응 모두 main이나 main이 호출하는 모듈로 옮긴다. 나머지 시스템은 모두 객체로 생성되었고, 모든 의존성이 연결되도록 한다. 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모르게 된다. 2. 팩토리 객체가 생성되는 시점을 애플리케이션이 결정할 때는 팩토리를 사용한다. 이런 경우 ABSTRACT FACTORY ..
클래스 체계 변수 목록이 가장 먼저 나온다. → 정적 공개 상수가 있다면 맨 처음에 나온다. 비공개 인스턴스 변수가 나온다. 공개 함수가 나온다. 클래스는 작아야 한다 하나의 클래스가 많은 책임을 가지면 안 된다. (SOLID 법칙 중 SRP 위반) 클래스 이름은 해당 클래스 책임을 기술해야 한다. 큰 클래스 몇 개가 아니라 작은 클래스 녀럿으로 이루어진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유 역시 하나다. 변경하기 쉬운 클래스 대다수의 시스템은 지속적인 변경이 가해진다. 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. (OCP 원칙) 결합도와 응집도 시스템의 결합도를 낮추면 유연성과 재사용성이 더욱 높아진다. 결합도가 ..
