- p.44
- 스프링을 사용하는 개발자들은 자연스럽게 자바와 엔터프라이즈 개발의 기본에 충실한 베스트 프랙티스를 적용할 수 있고, 이상적인 개발 철학과 프로그래밍 모델을 이해하게 되고, 좋은 개발 습관을 체득하게 된다.
- 스프링을 사용하는 개발자들이 스프링을 통해 얻게 되는 두 가지 중요한 가치가 있다면 그것은 단순함과 유연성이다.
2.1. 오브젝트와 의존관계 ¶
- p.61
- 잘 동작하는 코드를 굳이 수정하고 개선해야 하는 이유는 뭘까?
- 이런 말이 생각나네요 컴퓨터가 이해할수 있는 코드는 어느 바보나 다 작성할 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다 - 마틴파울러 - 서지혜
- p.62
- 가장 좋은 대책은 변화의 폭을 최소한으로 줄여주는 것이다.
- p.70
- 그런데 디자인 패턴은 설계 전략이기도 하지만 굉장히 편리한 커뮤니케이션 수단이기도 하다.
- p.73
- 변화의 성격이 다르다는 건 변화의 이유와 시기, 주기 등이 다르다는 뜻이다.
- p.211
- 템플릿이란 이렇게 바뀌는 성질이 다른 코드 중에서 변경이 거의 일어나지 않으며 일정한 패턴으로 유지되는 특성을 가진 부분을 자유롭게 변경되는 성질을 가진 부분으로부터 독립시켜서 효과적으로 활용할 수 있도록 하는 방법이다.
- p.217
- 이 문제의 핵심은 변하지 않는, 그러나 많은 곳에서 중복되는 코드와 로직에 따라 자꾸 확장되고 자주 변하는 코드를 잘 분리해내는 작업이다.
- p.223
- 전략 패턴에 따르면 Context가 어떤 전략을 사용하게 할 것인가는 Context를 사용하는 앞단의 Client가 결정하는 게 일반적이다.
- Context는 전달받은 그 Strategy 구현 클래스의 오브젝트를 사용한다.
- p.226
- DI의 가장 중요한 개념은 제3자의 도움을 통애 두 오브젝트 사이의 유연한 관계가 설정되도록 만든다는 것이다.
- 일반적으로 DI는 의존관계에 있는 두 개의 오브젝트와 이 간계를 다이내믹하게 설정해주는 오브젝트 팩토리(DI 컨테이너), 그리고 이를 사용하는 클라이언트라는 4개의 오브젝트 사이에서 일어난다.
- p.250
- 고정된 작업 흐름을 갖고 있으면서 여기저기서 자주 반복되는 코드가 있다면, 중복되는 코드를 분리할 방법을 생각해보는 습관을 기르자.
- p.257
- 템플릿과 콜백을 찾아낼 때는, 변하는 코드의 경계를 찾고 그 경계를 사이에 두고 주고받는 일정한 정보가 있는지 확인하면 된다고 했다.
- hamcrest.CoreMatchers에 대해서 : CoreMatcher로 테스트 코드를 만들 때 null 값은 비교나 not을 사용하는 것이 불가능합니다(ex. assertThat(tempObject, is(null)); -> 에러). 이건 null이 값이 아니기 때문인데, CoreMatcher에서 null 값을 쓸 때는 org.hamcrest.CoreMatchers의 notNullValue()와 nullValue()를 사용하시면 되겠습니다. http://jmock.org/javadoc/2.5.1/org/hamcrest/CoreMatchers.html
- p.283
- 예외는 처리돼야 한다.
- 예외를 처리할 때 반드시 지켜야 할 핵심 원칙은 한 가지다. 모든 예외는 적절하게 복구되든지 아니면 작업을 중단시키고 운영자 또는 개발자에게 분명하게 통보돼야 한다.
- p.284
- 굳이 예외를 잡아서 뭔가 조치를 취할 방법이 없다면 잡지 말아야 한다.
- p.290
- 예외를 회피하는 것은 예외를 복구하는 것처럼 의도가 분명해야 한다.
- p.317
- 애플리케이션의 로직을 담기 위한 예외는 체크 예외로 만든다.
5. 서비스 추상화 ¶
- p.320
- 의미 없는 숫자를 프로퍼티에 사용하면 타입이 안전하지 않아서 위험할 수 있다.
- p.321
- 그래서 숫자 타입을 직접 사용하는 것보다는 자바 5 이상에서 제공하는 이늄(enum)을 이용하는 게 안전하고 편하다.
- p.327
- 빠르게 실행 가능한 포괄적인 테스트를 만들어두면 이렇게 기능의 추가나 수정이 일어날 때 그 위력을 발휘한다.
- p.329
- 가장 많은 실수가 일어나는 곳은 바로 SQL 문장이다.
- p.330
- 두 번째 방법은 테스트를 보강해서 원하는 사용자 외의 정보는 변경되지 않았음을 직접 확인하는 것이다.
- 이것도 확인해야한다는 생각을 미처 못했다. - 김수경
- 테스트를 만들면 작성한 코드에 확신을 가질 수 있고 마음이 편해지는 건 사실이지만, 귀찮다고 대충 작성한 테스트는 오히려 찾기 힘든 버그와 사고의 원인이 될 수도 있으니 조심하자.
- p.331
- DAO는 데이터를 어떻게 가져오고 조작할지를 다루는 곳이지 비즈니스 로직을 두는 곳이 아니다.
- p.332
- 데이터 액세스 로직이 바뀌었다고 비즈니스 로직 코드를 수정하는 일이 있어서는 안 된다.
- p.335
- 이 정도 코드라면 한 번 살펴보는 것 만으로도 오류가 있는지 쉽게 찾아낼 자신이 있는 개발자도 있겠지만, 정말 뛰어난 개발자라면 아무리 간단해 보여도 실수할 수 있음을 알고 있기 때문에 테스트를 만들어서 직접 동작하는 모습을 확인해보려고 할 것이다.
- p.339
- 코드가 깔끔해 보이지 안는 이유는 이렇게 성격이 다른 여러 가지 로직이 한데 섞여있기 때문이다.
- p.345
- 객체지향적인 코드는 다른 오브젝트의 데이터를 가져와서 작업하는 대신 데이터를 갖고 있는 다른 오브젝트에게 작업을 해달라고 요청한다. 오브젝트에게 데이터를 요구하지 말고 작업을 요청하라는 것이 객체지향 프로그래밍의 가장 기본이 되는 원리이기도 하다.
- p.351
- 게다가 테스트의 기본은 자동화된 테스트여야 하니 사람이 간섭하는 것은 좋은 생각이 아니다.
- p.355
- 트랜잭션이란 더 이상 나눌 수 없는 단위 작업을 말한다. 작업을 쪼개서 작은 단위로 만들 수 없다는 것은 트랜잭션의 핵심 속성인 원자성을 의미한다.
- 따라서 중간에 예외가 발생해서 작업을 완료할 수 없다면 아예 작업이 시작되지 않은 것처럼 초기 상태로 돌려놔야 한다. 이것이 바로 트랜잭션이다.
- 하지만 여러 개의 SQL이 사용되는 작업을 하나의 트랜잭션으로 취급해야 하는 경우도 있다.
- p.356
- 모든 트랜잭션은 시작하는 지점과 끝나는 지점이 있다. 시작하는 방법은 한 가지이지만 끝나는 방법은 두 가지다. 모든 작업을 무효화하는 롤백과 모든 작업을 다 확정하는 커밋이다.
- p.362
- 비즈니스 로직을 담고 있는 UserService 메소드 안에서 트랜잭션의 경계를 설정해 관리하려면 지금까지 만들었던 깔끔하게 정리된 코드를 포기해야 할까? 아니면, 트랜잭션 기능을 포기해야 할까? 물론 둘 다 아니다. 스프링은 이 딜레마를 해결할 수 있는 멋진 방법을 제공해준다.
- p.371
- 이렇게 여러 기술의 사용 방법에 공통점이 있다면 추상화를 생각해볼 수 있다. 추상화란 하위 시스템의 공통점을 뽑아내서 분리시키는 것을 말한다. 그렇게 하면 하위 시스템이 어떤 것인지 알지 못해도, 또는 하위 시스템이 바뀌더라도 일관된 방법으로 접근할 수가 있다.
