벌써 2주차 미션이 끝났다. 미션을 진행하면서 시간이 너무 빨리 흘러가는 것 같다.
이번에 미리 생각해놨던 커밋메세지 포맷대로 작성을 하니 1차 미션때 보다는 가독성이 좋아진것 같다👍
이번 미션을 진행하며 설계 단계에서 도메인 모델을 기반으로 구조를 설계해보고 기능목록을 작성했다. 자동차 레이싱 게임이라는 모델을 정하고 거기서 객체들을 추출해서 사용했다. 그리고 객체들의 협력은 레이싱 게임의 통상적인 게임 규칙을 기반으로 설계했다. 이런 과정을 거치니 게임이 가지고 있는 규칙을 벗어나지 않는 변경사항에 대해서 전보다 쉽게 실마리를 잡을 수 있을 것 같아 내 코드에 어느 정도 확신이 섰다. 구현하는 과정에서는 객체들의 역할이 머릿속에 쉽게 정리돼서 방향성을 잃지 않고 구현할 수 있었다.
이후에도 추가로 OOP 관련 기본 서적을 읽어보며 자신을 이해시킬 수 있는 코드를 짜고 싶다.
이번 미션에서는 예외를 처리하는 요구사항이 추가됐는데 요구사항에 맞게 예외 처리를 해보며 최대한 많은 예외발생 케이스를 생각해보고 적용했다. 그런데 테스트 케이스에서는 통과됐던 시나리오가 실제로 실행하는 과정에서는 예상치 못한 예외를 발생시켰다. 그 원인은 바로 테스트 코드에서 있었는데 상위클래스의 예외 발생 유무만을 테스트 해서 미처 생각지 못했던 하위의 예외들이 테스트를 통과하게 됐기 때문이었다. 그래서 영문도 모른 채 엉뚱한 곳을 뜯어보며 원인을 찾는 데 시간을 허비했다. 이 과정에서 RuntimeException을 상속받는 예외들의 종류와 관계에 대해 찾아보며 공부하게 됐고 테스트 케이스의 중요성을 느꼈다. 꼼꼼한 테스트를 짜는 데 비록 시간이 걸리지만 결국 이게 시간을 버는 것 이라는 생각이 들었다.
1차 미션과 다르게 이번에는 특정 클래스의 원시 타입인 멤버필드와 기본 생성자가 정해져 있어서 원시값을 포장할 수 없었고 생성자를 통해서 유효성 검사도 할 수 없었다. 그래서 따로 전체 이름과 개별 이름, 이 두 개를 위한 유효성 검사 클래스를 만들었는데 이후에 예외 케이스가 추가될 때마다 두 배로 늘어나는 코드를 보면서 원시값을 포장했을 때의 이점을 한 번 더 생각하게 됐고 그 필요성을 느낄 수 있었다.
저번 미션부터 내가 상수명을 지을 때 그 값의 역할을 유추할 수 있는 이름이 아닌 추상적이거나 값 자체를 나타내는 이름을 짓는 경우가 간혹 있었다.
하나의 기능을 구현하고 꼭 리팩토링하는 시간을 가져 꼼꼼하게 프로그래밍 해나가야겠다.
상수명을 신경 써서 정하자
테스트케이스를 꼼꼼하게 작성하자
꼼꼼하게!!
