숫자야구

내일배움캠프 3주차가 지나갔다. 3주차는 숫자야구 과제가 있었는데, 숫자야구는 해 본 적이 있어서 과제 난이도 자체는 어렵지 않았지만 이번에도 내 기준을 가지고 객체지향적으로 코드를 짜는 것이 목표였기에 그 부분에 최대한 무게를 두고 구현했다. 이번 주에는 추가 과제같은 건 없어서 부담없는 마음으로 임했던 것 같다.

 

숫자야구

숫자야구는 작년 우테코 프리코스 과정에서 해 본 적이 있는 과제였다. 다만 작년에는 자바를 사용했으면서도 객체를 사용하여 코드를 짜는 법을 전혀 몰랐기에, main에서 모든 것을 다 해결하는 절차지향적인 방식으로 했던 기억이 있다. 따라서 이번 주차 과제도 문제를 해결하는 것 자체는 간단하지만 코드를 객체지향적으로, 그리고 기준을 가지고 짜는 것이 나의 숙제였다. 또 내가 해왔던 코딩 방식이 정말 확장에 유연한가? 를 확인하고 싶었고 실제로 기능 추가를 할 때 어떤 부분 때문에 변경이 어려운지를 알고 싶었기 때문에 일부러 필수 구현 요구사항 → 추가 기능요구사항1 → 추가 기능요구사항2 ... 순서로 구현했다.(원래는 어차피 다 할수 있으니까 최종 요구사항까지 스코프를 잡고 한 번에 구현했다) 
그럼에도 머리속으론 다음 스텝에 어떤 내용의 요구사항이 있는지 알고 있기 때문에 어느정도 염두에 두고 구현한 것도 있긴 했다. 그래도 변경의 여지가 있는 부분은 가능한 대로 분리하고, 필요한 부분을 Enum으로 처리하는 등 신경을 썼기 때문에 추가 요구사항을 구현할 때 큰 어려움이 없었던 것 같다. (사실 드라마틱한 코드 변경이 필요한 요구사항은 아니었다)

그러나 변경 후에 각 계층의 책임이 조금 달라졌고, 계층이 가지는 책임을 명확히 하기 위해 고민도 많이 하고 리팩토링도 여러 번 거쳤다. 그래서인지는 몰라도 괜찮은 피드백을 받은 것 같아 뿌듯했다. 그렇지만 아직 코드를 정확하게 제어하고 있지는 않다고 느꼈다. 예외처리 부분에서도 의도하지 않은 예외가 발생하는 경우가 있어 이 부분은 원인파악이 필요할 것 같다. 그 밖에도

• 게임 결과를 기록하는 클래스에서 전역 메서드와 전역변수를 가지고 있는게 옳은 방향인지
• 테스트에서 같은 sut 를 테스트할 때 하나의 테스트 메서드 안에서 케이스를 분리해 가며 작성하는게 좋은 방향인지

등 혼자 고민해서는 알 수 없는 문제들도 있었다. 이 부분은 최대한 내 생각대로 작성해서 제출했는데, 어느 부분에 대한 피드백이 궁금하다는 것을 써서 제출할 걸 하고 후회했다.

 

피드백

숫자야구 과제는 상세한 피드백을 받았다. 튜터님께서 크게 세가지 포인트를 짚어주셨는데, 

1. 저장하는 로직에 대한 추상화를 신 쓸 것
2. 데이터만을 다루는 클래스의 경우 data class 를 활용해 볼 것
3. 테스트는 함수단위로 나누는 것을 권장

위 세 가지였다. 특히 첫 번째 피드백은 아는 문제를 틀렸을 때 처럼 아차 싶었다가도, 이번에 지적받지 않았다면 다음에도 중요하지 않게 여겼을 것 같아서 이번에 피드백 해 주신 게 다행이라고 느껴졌다. 다음에는 저장하는 방식을 구현할 때 요구사항의 변경을 고려하여 구현하게 될 것 같다.
data 클래스는 처음 배우는 내용인 만큼 간단히 정리해서 글로 남겨놓을 생각이고, 아마 다음 프로젝트 또는 과제에 적용해 볼 수 있을 것 같다.
테스트에 대한 피드백은 제출할때까지도 고민했던 부분이었다. 하나의 메서드를 테스트 하는 데 여러 개의 테스트 케이스가 있다면 모든 케이스를 나누고 별도의 이름을 가진 테스트 메서드를 작성하는게 맞는 건지 확실하게 알지 못했다. 그게 함수들이 정확한 책임을 가지고 테스트를 하게끔 하는 방법이라고 생각은 했지만 제출 당시는 코드가 불필요하게 길어지고 지저분해 보일 수 있다는 생각이 들어서 하나의 메서드에 모든 테스트 케이스들을 포함시켰다. 다음에 테스트를 작성할 때는 메서드 내에서도 테스트케이스를 나누어 여러 테스트메서드를 만들어야겠다.

 

회고

3주차에는 2주차에 모자랐던 부분을 개선하려는 시도를 했다. 이를 위해 이번 주에 목표로 했던 것은 알고리즘 문제 풀기였는데, 많이는 아니지만 알고리즘 문제에 손을 대기 시작했다는 것에 의미를 부여하기로 했다.(...) 다행인 것은 전에 문제를 풀 때는 c언어를 하던 때의 습관이 남아서 (내장함수를 안쓰고 다 구현해서 쓰는) 시간이 꽤 오래걸리고 실수도 많았는데, 내려놓고 kotlin 의 내장함수를 맘껏 사용하니 로직에만 집중할 수 있고 문제 푸는것도 훨씬 빨라진 것을 느꼈다. 다음주에는 조금 더 많은 알고리즘 문제를 풀어보고, 손도 안대고 있던 SQL 문제도 시작해야겠다. 반드시 한문제 이상은 풀 생각이다.

팀원들과도 새로운 과제에 대해 코드 리뷰를 제안해서 각자 피드백하는 시간을 가졌다. 남의 코드를 보는건 항상 익숙하지 않고 시간도 오래 걸리는 일인데다가 내 코가 석자라 코드에 어떤 문제나 결함이 있는것을 발견하기도 힘들었다. 그렇지만 코드를 보는 눈을 익히는 연습이라고 생각하고 앞으로도 코드를 공유하는 것은 적극적으로 제안할 생각이다.