2장. 효과적인 피드백 활용 레거시 코드 변경 알고리즘 변경 지점을 식별한다. 테스트 지점을 찾는다. 의존관계를 깬다. 테스트 루틴을 작성한다. 변경시키고 리팩토링한다. 3장. 감지와 분리 레거시코드를 원자 단위까지 분리하여 변경지점을 식별한다. 의존관계를 가진 객체의 경우 Mock/Fake 객체를 사용하기 위해 인터페이스로 의존성을 깬다. 테스트 루틴을 작성 -> 수정 -> 테스트 성공 -> 리팩토링 단계를 반복한다. 4장. 봉합 자바에서는 클래스패스를 이용한 다른 버전의 클래스를 만들수 있다. 5장. 레거시 코드를 위한 도구 JUnit 6장. 고칠 건 많고 시간은 없고 발아(Sprout) Method / Class: 메서드/클래스를 추가 포장(Wrap) Method / Class: 기존 메서드/클래스를 포장하는 메서드/클래스를 추가(데코레이터 패턴) 7장. 코드 하나 바꾸는데 왜 이리 오래 걸리지? 의존관계 반전 원칙 당신의 코드가 인터페이스에 종속되는 경우, 그 의존관계는 사실 경미한 수준으로 눈에 잘 띄지 않는다. 인터페이스가 변하지 않는 한, 코드를 변경시킬 필요는 없다. 또한 인터페이스들은 그들 아래에 위치한 코드에 비해 훨씬 적은 빈도로 변경된다. 인터페이스를 하나 가지고 있는 경우, 그 인터페이스를 구현하는 클래스들을 편집하거나 그 인터페이스를 구현하기 위한 새로운 클래스들을 추가할 수 있다. 물론 그 인터페이스를 사용하는 코드에 영향을 주지도 않는다. 이런 이유 때문에 구체 클래스보다는 인터페이스나 추상 클래스에 종속되는 편이 좋다. 덜 변하는 것들에 종속됨으로써 특정 변경이 초래할지도 모를 대규모 재컴파일 사태의 위험을 최소화할 수 있다. 8장. 특징, 어떻게 추가할까? 테스트 주도 개발 실패 테스트 케이스를 작성한다. 컴파일되게 만든다. 테스트에 통과하도록 만든다. 중복을 제거한다. 반복한다.
AOP Aspect Oriented Programming 독립적인 모듈화가 불가능한 트랜잭션 경계설정과 같은 부가기능을 모듈화하는 작업 Aspect: 핵심기능에 부가되어 의미를 갖는 특별한 모듈 AOP는 Aspect를 분리함으로써 핵심기능을 설계하고 구현할 때 객체지향적인 가치를 지킬 수 있도록 도와주는 것(토비의 스프링) Transaction 더 이상 나눌 수 없는 단위 작업 SQL을 이용해 다중 로우의 수정이나 삭제를 했을 때, 일부는 되고 나머지는 안되는 경우는 없다. DB가 트랜잭션을 보장해 준다고 믿음. 여러 SQL이 실행될 때, 어느 한 SQL이 장애가 발생하면 이전에 실행된 SQL 작업은 취소해야 하는데, 이 취소 작업을 "트랜잭션 롤백" 여러 SQL이 실행될 때, 모든 SQL이 성공적으로 마무리했다면, DB에 해당 SQL 작업들을 확정해야 하는데, 이 확정 작업을 "트랜잭션 커밋" JDBC의 트랜잭션은 default 로 setAutoCommit(true) 이므로, 프로그램적으로 여러개의 SQL에 대하여 트랜잭션 경계설정을 하기 위해서는 autoCommit을 false로 설정해야 한다. CGLIB Code Generator Library 런타임에 동적으로 클래스의 프록시를 생성함 JDK Dynamic Proxy 보다 더 빠르다. JDK Dynamic Proxy 의 경우 리플렉션을 이용해 인터페이스의 구현 클래스를 위임하는 프록시 클래스를 이용하며, CGLIB는 클래스 파일을 상속받아서 프록시 클래스를 만들어 낸다. JDK Dynamic Proxy(인터페이스 필요), CGLIB(인터페이스 필요없음) AspectJ 는 스프링 컨테이너를 사용하지 않는 경우에도 프록시 클래스 생성을 해주며, 런타임시 바이트코드를 조작하는 방식을 사용한다. IOC 제어권의 이전을 통한 제어관계 역전 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않고 생성하지