점진적인 개선
TDD를 통해 점진적으로 개선하자.
충분한 테스트 케이스가 작성되어 있다면 리팩토링이 두렵지 않다.
여러 차례의 반복된 개선을 통해서 테스트 케이스가 실패하지 않는 방향으로 점진적으로 개선하자.
한 번에 구조를 크게 바꾸면 개선 전과 똑같이 프로그램을 실행하기 어렵다.
저자는 Args 유틸리티를 수정하면서 약 30회에 걸친 수정을 진행한다. 한정된 일정 안에서 안전하게 리팩토링을 진행하기에 아주 좋은 방법이지만 시간이 넉넉하다면 조금 더 큰 규모로 리팩토링 하는 것도 괜찮지 않을까?
FitNess(테스트 라이브러리)에 맞춘 코드 변경
FitNess에서 boolean이 아닌 인수로 getBoolean을 호출했을 때 false를 반환하는 부분을 해결하기 위해서 ClassCastException에 대한 try-catch코드를 삽입.
테스트 때문에 별도의 코드를 로직 속에 삽입하는 것은 좋지 않다고 생각한다. 저자도 주석에서 이 부분을 해결하기 위해 FitNess용 단위 테스트를 따로 추가했다.
Marshaler
Marshalling: 한 객체의 메모리에서 표현방식을 저장 또는 전송에 적합한 다른 데이터 형식으로 변환하는 과정이다. 또한 이는 데이터를 컴퓨터 프로그램의 서로 다른 부분 간에 혹은 한 프로그램에서 다른 프로그램으로 이동해야 할 때도 사용된다. 마셜링은 직렬화(serialization)와 유사하며 한 오브젝트, 여기서는 직렬화 된 오브젝트로 멀리 떨어진 오브젝트와 통신하기 위해 사용된다.
리팩토링이 진행되는 내내 Marchaler라는 단어의 의미를 제대로 이해하지 못해 소스코드가 이해가 어려웠다. 예시 코드 속에서는 ArgumentMarshaler 클래스의 역할이 입력 받은 문자열을 스키마에 맞춰 해석된 결과를 저장하는 역할이라 Marshaler라는 단어를 붙인 것 같다. 책 초반에 기술 개념에는 기술 이름이 가장 적합하다고 했었는데 자바 개발자들에게는(혹은 나 말고 다른 개발자들은) Marshalling이라는 개념이 익숙한 걸까?
방어적인 코드 작성에 대해
개발을 하다보면 예시에서 나온 Args 유틸리티처럼 처리해야 하는 경우의 수가 늘어나는 경우가 종종 있다. 앞으로 경우의 수가 추가되는 것에 대비해서 처음부터 유연하게 코드를 작성하는 방어적인 코드 작성(이렇게 부르는게 맞는지 모르겠다.)에 대해 이번 장에서 다시금 생각해보게 되었다. 처음에 너무 strict하게 코드를 작성하면 훗날 유지보수에 고생할 수 있다는 관점과 앞으로의 일을 알 수 없는데 너무 유연하게 작성하려고 하는 것은 인력/시간의 낭비가 될 수 있다는 관점이 있는데 이 중간을 잡는 것이 참 어려운 문제인 것 같다.
