요즘 토비의 스프링 책에서 배운 내용들이 내 업무 현장에서 춤을 추는 것 같다.
배우고 학습한 것만 보인다
오늘 안테나의 위성 추적 경로를 최적화 하기 위한 간단한 알고리즘을 설계하고 구현하는 작업을 했다. 테스트 방법을 고민하다 지난주 토비의 스프링 책에서 읽었던 ‘단위 테스트 고립하기’라는 전략이 생각났다. 평소였다면 경로 보정 알고리즘을 적용하고 e2e 관점에서 안테나 시뮬레이터까지 구동하며 컴포넌트 전체를 테스트했을 텐데 잠시만 고민하니 더 나은 테스트 방법이 생각난다. 이미 다른 테스트 케이스에서 안테나 추적 목록이 주어지면 위성 추적을 정상적으로 하는지는 테스트가 완료되었다. 그러니 이번에는 경로 최적화 모듈만 따로 때어서 원하는 최적화 목록을 생성하는지만 검증하면 된다. 생성된 목록으로 안테나가 위성을 잘 추적하는지는 정상이라고 가정할 수 있겠다. 자연스럽게 해당 모듈을 별도의 역할을 하는 객체로 분리하게 되고, 인터페이스를 정의해서 DI로 기존 모듈에서 주입해 주도록 큰 구조를 잡는다. 테스트 클래스도 해당 모듈만 검증하도록 별도로 구분한다. 토비의 스프링 책을 읽으며 내가 우물안 개구리였음을 느낀다. 다른 사람의 방법을 배우지 않더라도 혼자 삽질을 하고 고민 하다보면 분명히 나아지고 성장하는 부분이 있다. 그러나 한계가 있음을 절실히 깨닫는다. 배우고 학습한 것만 현업에 그대로 나타난다. 본적이 없는 것은 더디게 나타나거나 절대 나타나지 않을지도 모른다. 지난주 까지 배웠던 몇 가지 것들을 현업에 더 활용해 보게 되어 아래 더 기록해 본다.
여러 성격의 코드가 한데 뭉친
토비의 스프링 책 5장에 여러가지 성격의 코드들이 한데 뒤섞여 있는 if-else 체인 비지니스 로직 코드가 등장한다. 이 코드를 개선하는 가운데 ‘데이터를 가져오지 말고 작업을 요청한다’라는 객체지향 프로그래밍의 기본 전략이 인상깊었다. 오늘 약간 복잡한 알고리즘을 작성하다보니 처음에 나도 모든 내용이 한데 뒤섞여 있는 if-else 체인 코드를 만들게 된다. 결과적으로 경로 보정이 필요한 영역을 구분하고 각각의 Position이 해당 영역에 포함되었는지 체크하는 모듈 하나와 실제 보정을 수행하는 모듈 둘로 나누니 코드가 훨씬 깔끔해 졌다.
컴파일 안되는 사용자 코드 먼저
서비스 코드를 작성하며 최상위 계층의 사용자 코드를 먼저 작성하는 시도를 해보았다. 그리고 지난주에 배운 것 처럼 IDE의 자동 완성 기능과 GitHub Copilot 기능을 적극 활용해 보았다. 역시 빨강색 단어들이 사라지는 것을 보며 뭔지 모를 짜릿함이 있고, 최종 사용 모듈 관점에서 코드를 작성하니 사용하는데 꼭 필요한 코드에만 집중하게 되는 장점이 있다. 계속 이렇게 해봐야지.
점진적 접근과 학습 테스트
지난주에 안테나의 위성 추적 목록과 실제로 추적된 목록을 비교 검증하는 코드를 작성했었다. 코드를 작성하며 두 목록이 일치하는지만 검증하고 실제 추적된 목록이 1초 단위로 추적된 것이 맞는지 검증하지는 않았다. 둘을 한 번에 하려니 뭔가 복잡했고 진도가 더딜 것 같아서 였다. ‘한 번에 다루어야 할 공이 내 머리에 담을 만하게 하자’ 라는 일종의 전략이었는데 오늘 최종 시간 검증까지 수행하는 테스트 코드를 완료 했다. 첨엔 목록이 같은지만 비교하고, 그 다음에 각 항목이 1초 차이로 처리되었는지 테스트 코드를 확장해 나간거다. 잠시 돌아보면 1초 차이를 검증하는데 어떤 라이브러리를 사용해야할 지 확신이 없었던 것 같다. LocalDateTime과 Duration 클래스의 여러 메서드를 테스트 코드로 학습하며 시간 차이를 측정하는 방법에 능숙해 진 것 같다. 그래서 오늘 관련 코드를 심플하게 아주 빠르게 작성할 수 있었던 것 같다. 요즘 토비의 스프링 책에서 배운 내용들이 내 업무 현장에서 춤을 추는 것 같다.
