하... 이 문제는 39번 시도 끝에 통과한 문제다. 극히 일부만 캡쳐했지만 하다하다 오기가 생겨서 계속 시도하다 보니 이렇게까지 제출 횟수가 늘어났던것 같다. 42%에서 시간초과가 계속 나오는 것을 보고 이래저래 고치다보니 틀렸습니다가 나오기는 했지만 ㅎㅎㅎ 그래도 다양한 반례를 테스트 해보면서 로직상의 문제는 크게 없다는 것을 깨달았다. 시간초과가 문제였을 뿐... 어쨌든 하다가 너무 짜증나서 다른 사람의 풀이를 봐야지 하다가 하나의 차이점을 발견했다. copyTreeAge =deepcopy(treeAge[nr][nc]) copyTreeAge.appendleft(1) treeAge[nr][nc] = copyTreeAge 나는 위의 코드처럼 깊은 복사를 해주어야만 appendleft를 해도 treeAg..

AOP가 필요한 상황 모든 메소드와 호출 시간을 측정하고 싶은 경우 공통 관심 사항(cross-cutting concern) VS 핵심 관심 사항(core concern) 회원 가입 시간, 회원 조회 시간 측정하고 싶은 경우 예시 만약 각 메서드의 실행 소요 시간을 알고싶다고 하면, 여러가지 문제점이 생긴다. 회원가입, 회원조회 등의 메소드는 핵심 관심 사항인데 비해, 시간을 측정하는 로직은 공통관심사항이다. 핵심 비즈니스 로직과 시간측정 로직이 섞이면 유지보수 및 변경이 어렵다. 시간을 측정하는 로직을 별도의 공통 로직으로 만들기는 어렵다. 따라서 이렇게 시간 측정 로직을 핵심 비즈니스 로직에 붙여서 사용하는 것이 아니라, 시간 측정 로직을 한 곳에 모두 모아 내가 원하는 곳에 적용하는 방법을 사용한다..

스프링 부트와 JPA 기반 위에 스프링 데이터 JPA 프레임 워크 : JPA를 편리하게 사용하도록 도와주는 기술 스프링 부트와 JPA만 사용해도 개발 생산성이 많이 증가되고, 개발해야하는 코드도 확연히 줄어들게 된다. 여기에 스프링 데이터 JPA를 사용하면, 기존의 한계를 넘어서 리포지토리 구현 클래스 없이 인터페이스 안으로 개발을 완료할 수 있게된다. 또한 반복 개발해왔던 CRUD 기능도 스프링 데이터 JPA가 모두 제공한다. * 실무에서 ERD를 사용한다면, 스프링 데이터 JPA는 필수이다. 인터페이스를 통한 기본적인 CRUD 기능 제공 findByName(), findByEmail() 처럼 메서드 이름만으로 조회 기능 제공 페이징 기능 자동 제공 SpringDataJpaMemberRepository..

JPA JDBC에서 JDBC Template으로 바뀌면서 개발자가 작성해야하는 반복된 코드는 확 줄었지만 SQL은 직접 모두 작성해야했다. 그런데 JPA는 이런 기본 SQL도 직접 만들어서 실행해준다. 또한 SQL과 데이터 중심의 설계에서 객체 중심의 설계로 패러다임을 전환할 수 있다. 따라서 개발 생산성을 높일 수 있게된다. 마치 객체를 메모리(memoryMemberRepository)에 넣듯이 JPA가 중간에서 DB에 SQL을 날리고, DB에서 데이터를 가져오는 것을 처리한다. JPA 라이브러리 추가 및 설정 Entity 맵핑 JPA는 인터페이스만 제공이 되는 것이다. hybernate, eclipse 등이 구현 기술이 된다. 즉, JPA 인터페이스에 hybernate만 사용한다고 생각해도 무방하다...

스프링 JDBC Template : 순수 Jdbc와 동일한 환경설정을 하면 된다 스프링 JDBC Template과 MyBatis 같은 라이브러리는 JDBC API에서 본 반복코드를 대부분 제거해준다. 하지만 SQL은 직접 작성해야한다. package hello.hellospring.repositroy; import hello.hellospring.domain.Member; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.jdbc.core.RowMapper; import org.springframework..

@SpringBootTest 스프링 컨테이너와 테스트를 함께 실행한다. @Transactional @AfterEach로 데이터를 지우는 역할을 테스트케이스에 이 어노테이션이 붙게 되면 대신한다. 즉, db에 데이터를 insert 한 이후에 commit 하지 않고 rollback 하는 역할을 수행하기 때문에 실제 데이터는 db에 반영되지 않고 같은 데이터로 반복 테스트를 하여도 테스트 에러(예외)가 나지 않는다. 이전에 했던 MemberServiceTest.java를 단위테스트 라고 한다면, 이번 MemberServiceIntegrationTest.java와 같은 테스트를 통합테스트 라고 한다. * 단위테스트를 하는 것이 좋은 테스트일 확률이 높으며, 스프링 컨테이너 없이 테스트하는 훈련을 해야한다.