지난주 막판은 졸업식을 다녀오고, 주말에는 피드백 받은 내용 바탕으로 코드를 수정하고, 쉴 새 없이 바빴다. 일요일 저녁에는 보이는 라디오 회식까지 해서 더 바빴다. 새벽까지 다같이 광란의 파티를 벌이는 바람에...
문제는 졸업식을 함께한 사람들이 단체로 몸살이 나서 코로나 검사를 받았더니 벌써 몇 명이나 신속항원검사에서 양성이 나왔다는 점이다. 나는 음성이 나왔지만, 문제는 유증상이다. 아침에 일어났을 때는 어제 회식의 여파라고만 생각했는데 점점 몸살기운과 인후통이 올라오고 있다... 우테코 하느라 진짜 얼마만에 나간건지도 모르겠는데 하필 그날 코로나 이슈라니...
자동차 경주 리팩토링
리뷰어 제이가 다시 한 번 리뷰를 남겨주었다. 이번에는 수정 요청 사항이 많지는 않았는데, 많지 않은 지적이 대부분 깊게 생각해볼만한 부분이었다.
model과 view의 책임
먼저 String을 콤마를 기준으로 자르는 로직이 Cars(model 계층)에 있을 필요 없이 중복 검사나 유효성 검사는 model로 넘어오더라도 String을 잘라서 list로 만들어 주는 것은 view 계층에서 해도 되지 않겠냐는 의견이었다. 생각해보니 nameString을 자르는 것을 굳이 Cars에서 할 필요가 없이 Cars는 딱 자동차 생성에 필요한 list만 받아 오는 것이 맞는 것 같고, 지금 부여한 책임은 Cars에게 불필요한 책임인 것 같아서 제이의 말대로 해당 로직을 view로 옮겨주었다.
인터페이스를 활용한 테스트
CarTest와 WinnersTest는 테스트 내에서 필요에 따라 Car를 전진시키는 로직이 있는데, 현재 게임의 자동차 전진 조건이 랜덤 넘버 4 이상이기 때문에 전진이 필요한 자동차의 goOrStop() 메소드에 4 값을 넣어서 전진시켰다.
해당 부분에 대해 제이가 위와 같은 피드백을 주었다. 음... 생각해보니 제이의 말이 맞다. 지금은 해당 메소드를 호출하는 곳이 적지만, 만약 Car.goOrStop() 메소드를 수많은 테스트에서 사용하는데 전진 규칙이 바뀌게 되면 테스트를 일일이 다 찾아서 수정해야 한다.
인터페이스를 이용하여 테스트하는 방식은 예전에 데일리 미팅 크루들과 이야기를 나누어 봤었는데, 다들 랜덤 값에 대한 테스트를 못하기 때문에 대체 방법으로 인터페이스 구현체를 이용한 것이었다. 당시에 나는 랜덤이 개입하는 로직에 대해서는 모두 테스트하지 않고, goOrStop()은 어떤 값이든 호출시에 파라미터를 받아서 해당 값으로만 전진/정지를 판단했고 그에 대한 테스트를 진행했기 때문에 굳이 인터페이스로 분리하는 방식이 필요하지 않다고 느꼈었다. 하지만 생각해보니 규칙의 변경에 테스트가 유연하게 대처할 수 없는 구조라는 제이의 피드백이 옳다. 그래서 다음 링크를 참조하여 인터페이스를 사용하여 테스트를 유연하게 만들었다.
이펙티브 자바 스터디
이펙티브 자바 스터디 첫 오티를 했다. 진행 방식을 확정하고 스터디 내부 규칙을 정하는 시간을 가졌는데, 확실히 여러 사람이 모여서 논의하니까 좋은 방안들이 여럿 올라왔다. 오티 전이 마침 3기 수료생 웨지의 효과적인 스터디를 하는 법 특강이었기 때문에, 다들 스터디 진행 방향에 대한 생각을 하고 오티를 들어올 수 있어서 좋았다.
우테코 4기 내에서 처음 만든 스터딘데, 이펙티브 자바 책이 워낙 방대해서 솔직히 조금 걱정이 되기는 한다. 아무래도 첫 스터디인 만큼 부족한 부분도 있을테고. 하지만 스터디를 진행하면서 부족한 점을 피드백해가며 조금씩 조정해 나간다면 효과적인 스터디를 꾸려나갈 수 있을 것 같다.
내일부터는 로또 미션 페어 프로그래밍도 시작될테고, 스터디 준비도 해야 하고... 쉴 시간 없이 바쁠 것 같다. 큰일이다. 와중에 코로나 양성까지 나오는 최악의 상황만 아니었으면 좋겠다.
