토비의 스프링 '3장 템플릿'을 읽으며 인상깊었던 내용, 배운점 등을 정리합니다.
* 토비의 스프링 | 3장 템플릿 (독서메모)
* 토비의 스프링 | 변하는 것과 변하지 않는 것을 분리하는 과정
변하지 않는 가치
매 장을 읽을 때 마다 새롭고 좋습니다. 3장이 변하지 않는 것과 변하는 것을 분리하는 개념이 나오는데 책에는 스프링이 버전업 되어도 변하지 않는 가치가 풍성하게 담겨있다는 생각이 듭니다. 3장에서 하나의 메서드로 거대하고 복잡하게 구현된 코드에서 변하는 것과 변하지 않는 것을 분리하며 객체지향의 핵심 원칙(개방폐쇄원칙)을 점진적으로 구현해 나가는 과정을 보여주시는데 마치 라이브 코딩을 보는 것 같았고 더 좋았던 점은 동영상과 다르게 저의 페이스에 맞추어 볼 수 있어서 너무 좋았습니다. 그래서 이번 장에서 템플릿/콜백 패턴을 구현하는 점진적인 과정을 따로 글로 정리해 보기도 했습니다.
다양한 선택지와 이유
그리고 개선 과정에 어떤 설계 결정 사항들에 대한 논리적인 이유를 설명해 주셔서 다양한 선택지와 그걸 선택하면 좋은 이유에 대해 알게 되었습니다. 책을 읽으면서 생각의 폭을 넓히게 된 것 같아 좋았습니다.
- 작은 코드를 Local 클래스를 선언하면 좋은 이유
- 어떤 경우에 인터페이스 대신 직접 DI를 해도 좋은 이유
숨겨진 역사
3장 초반에 예외 처리하는 길다란 코드가 나옵니다. 사실 최근에 자바나 스프링에 입문했다면 이런 예외 코드를 정석으로 작성해본 사람이 거의 없을 것 같습니다. try-with-resource 문이 자동화해 주기도 하고 AOP가 적용된 다양한 기술들이 복잡한 코드를 숨겨 주는 것 같습니다. 그러나 코드에도 역사가 있는 것 같습니다. 사람의 역사는 지나가서 책으로 남고 어떤 교훈으로 전해지지만 코드의 역사는 어딘가에 숨겨져 있는 것 같습니다. 이 숨겨져 있지만 어딘가에 실존하는 코드들을 보여주셔서 좋았습니다.
이 정도로 알 필요가 있을까?
책의 마지막에 간결하게 한 줄로 정리된 결과를 봅니다. 아래 코드를 보면 템플릿/콜백 패턴이 내부에 구현되었다는게 전혀 드러나지 않습니다. 완벽한 추상화란 생각이 들면서 나는 저 서비스를 사용하는 입장에서 왜 템플릿/콜백 패턴 같은 것을 알아야 할까 질문해 보게 되었습니다. 곰곰이 생각해 보니 우리는 프레임워크의 사용자지만 반대로 우리의 사용자를 위해 프레임워크 같은 애플리케이션을 만듭니다. 우리도 애플리케이션을 더 낫게(변경에 유연하고, 확장하기 쉽게) 만들기 위해서 선배들이 먼저 경험하고 만들어둔 좋은 것들을 배우면 프레임워크를 확장한 애플리케이션을 만들기에 유익하다는 결론을 내리게 됩니다.
jdbcTemplate.queryForInt("select count(*) from users"); 컴파일이 안되는 코드조차 먼저 (TDD)
3장 뒷 부분(템플릿/콜백의 응용)에 TDD를 통해 코드를 작성하는 부분이 나옵니다. 최근에 TDD에 관심이 있어서 인상 깊은 구절이 있었습니다. 예제에서 테스트 코드를 먼저 작성하고 ‘아직 테스트 코드만 있으니 컴파일도 안 될 것이다’ 말이 등장합니다. 저는 TDD를 시도할 때 항상 런타임에 실패하는 테스트 코드를 먼저 작성하려고 하거든요. 그래서 컴파일은 통과하는 코드를 최소한 작성해야 했어요. 그러기 위해서는 테스트에서 의존하는 여러 클래스들의 의존에 의존에 의존 관계의 껍데기 클래스를 다 정의해야 컴파일이 성공되는 경우가 대부분이었습니다. 그러면 약간 TDD가 아닌것 같은 느낌을 받기도 했었습니다. 토비님의 방법을 보고 컴파일에 실패하는 진짜 최상위 테스트 코드만 먼저 작성하는 것의 장점이 있겠단 생각이 들었어요. 의존하는 클래스들의 이름 조차도 사용자 관점에서 선언적으로 작성해 보고 하나씩 컴파일 단계부터 통과하게 만들어 가는 것이 더 낫겠다는 생각이 들었습니다. 다음에 이 방법을 한 번 도전해 보려구요. (책을 더 읽다 보니 테스트 클래스 내 변수 선언 조차 나중에 작성하는 방법을 사용하네요!)
문맥을 활용한 네이밍
jdbcContextWithStatementStrategy() 메서드를 다른 클래스에서도 공유할 수 있도록 JdbcContext라는 클래스로 분리하고 workWithStatementStrategy() 메서드를 만드는 걸 보며 Naming이 장난아니다라는 생각이 들었습니다. Naming이 너무 길어지면 패키지, 클래스, 메서드 등의 컨텍스트를 사용하라는 조언을 책에서 보았는데 살아있는 예제를 보는 것 같습니다.
두 단어의 패키지 이름
패키지 이름에 반드시 한 단어만 사용해야 한다는 강박관념이 있었는데 두 단어“leaningtest”를 쭉 소문자로 이어서 사용하신 걸 보고 약간의 강박관념에서 벗어나게 되었습니다.
적은 클래스 파일 개수
같은 일을 한다면 클래스 파일 개수 조차도 적게 만드는 것이 좋을 때가 있다는 한 가지 선택지를 배웠습니다.
