[9장] 우리가 사는 시간
자, 그렇다면 통화 개념을 어떻게 구현하길 원하는가? 아차, 실수. 다시 해보자. 회초리가 나오기 전에 말을 바꿔야 겠다. 자, 그렇다면 통화 개념을 어떻게 테스트하길 원하는가? 됐다. 일단 매는 피했다.
객체들이 필요한 만큼만 만들어지도록 하기 위해 경량 팩토리(flyweight factories)를 사용할 수 있을 것이다.
우린 두 클래스를 모두 포함할 수 있는 동일한 구현을 원한다.
이제 두 currency()가 동일하므로 변수 선언과 currency() 구현을 둘 다 위로 올릴(push up) 수 있게 됐다.
정적 팩토리 메서드로 옮긴다면 두 생성자가 동일해질 것이고, 그렇다면 공통 구현을 만들 수 있을 것이다.
보통 짧은 중단이 필요할 경우에 이를 흔쾌히 받아들이는 편이다. 물론 짧은 것만이다. 단, 하던 일을 중단하고 다른 일을 하는 상태에서 그 일을 또 중단하지 않는다. - 짐 코플린
TDD를 하는 동안 계속 해주어야 하는 일종의 조율이다. 종종걸음으로 진행하는 것이 답답한가? 그러면 보폭을 조금 넓혀라. 성큼성큼 걷는 것이 불안한가? 그럼 보폭을 줄여라. TDD란 조종해 나가는 과정이다. 정해진 올바른 보폭이라는 것은 존재하지 않는다.
[정리]
-큰 설계 아이디어를 다루다가 조금 곤경에 빠졌다. 그래서 좀 전에 주목했던 더 작은 작업을 수행했다.
-다른 부분들을 호출자(팩토리 메서드)로 옮김으로써 두 생성자를 일치시켰다.
-팩토리 메서드를 사용하도록 만들기 위해 리팩토링을 잠시 중단했다.
-비슷한 리팩토링을 한번의 큰 단계로 처리했다.
-동일한 생성자들을 상위 클래스로 올렸다.
[10장] 흥미로운 시간
우리에겐 깔끔한 코드와, 그 코드가 잘 작동한 거라는 믿음을 줄 수 있는 테스트 코드들이 있다. 몇 분 동안 고민하는 대신 그냥 수정하고 테스트를 돌려서 컴퓨터에게 직접 물어보자. 컴퓨터라면 10초에서 15초 사이에 대답할 수 있는 문제를 놓고 최고의 소프트웨어 엔지니어들이 5분에서 10분동안 고민하곤 한다. 가끔은 그냥 컴퓨터에게 물어보는 것도 좋다.
이미 빨간 막대 상태인데 이 상태에서는 새로운 테스트를 작성하지 않는 게 좋을 것 같다.
빨간 막대인 상황에서는 테스트를 추가로 작성하고 싶지 않다. 하지만 지금은 실제 모델 코드를 수정하려고 하는 중이고 테스트 없이는 모델 코드를 수정할 수 없다. 보수적인 방법을 따르자면 변경된 코드를 되돌려서 다시 초록 막대 상태로 돌아가야 한다.
[정리]
-두 times()를 일치시키기 위해 그 메서드들이 호출하는 다른 메서드들을 인라인시킨 후 상수를 변수로 바꿔주었다.
-단지 디버깅을 위해 테스트 없이 toString()을 작성했다.
-Franc 대신 Money를 반환하는 변경을 시도한 뒤 그것이 잘 작동할지를 테스트가 말하도록 했다.
-실험해본 걸 뒤로 물리고 또 다른 테스트를 작성했다. 테스트를 작동했더니 실험도 제대로 작동했다.
댓글