[우아한테크코스] 안드로이드 레벨1 자동차 경주 미션 회고

 

 

우테코에 들어와서 첫 미션을 마쳤다!

첫 미션은 프리코스 2주차 미션과 동일한, 자동차 경주였다.

조금 늦은 감이 있지만.. 이번 미션에 대한 회고를 작성하려 한다.

 

 

 

미션 관련 링크

자동차 경주 레포지토리

https://github.com/kimhm0728/kotlin-racingcar
자동차 경주(구현) 1단계 PR

https://github.com/woowacourse/kotlin-racingcar/pull/100

자동차 경주(리팩터링) 2단계 PR
https://github.com/woowacourse/kotlin-racingcar/pull/116

 

 

 

코드 리뷰 받은 코멘트들 

변경에 유연한 테스트 함수명을 사용하자.

기존에는 `자동차 이름이 다섯 글자가 넘는 경우 예외가 발생한다`라는 함수를 작성했다.

하지만 자동차 이름 길이에 대한 요구사항이 변경될 경우, 테스트 함수명도 변경해야 한다는 피드백을 받았다.

리뷰어님 피드백 이후 `자동차 이름이 최대 길이를 넘는 경우 예외가 발생한다`와 같은 함수명으로 수정했다.

 

 

테스트 어려운 부분을 테스트하기

랜덤 요소가 포함된 로직을 테스트하려면 어떻게 해야할까?

main 모듈에서는 랜덤 로직으로 구현하고, test 모듈에서는 랜덤 로직이 아닌, 테스트 가능한(값을 예상할 수 있는) 로직으로 구현해야 한다.

즉, 한 부분을 유연하게 바꿔낄 수 있어야 한다.

먼저 랜덤한 로직이 들어갈 부분의 타입을 interface로 대체한다.

그리고 main 모듈에서는 랜덤 로직이 포함된 구현체를, test 모듈에서는 직접 값을 지정한 구현체를 외부에서 주입했다.

이를 "전략 패턴"이라고 한다.

 

 

객체가 어떻게 출력되어야 할지에 대한 부분은 출력 쪽에서 구현하기

나는 객체의 상태를 객체 자신만 알고 있고, 외부에서 이 객체를 출력하고자 할 때만 출력 형식에 맞게 자신의 상태를 적절히 가공해서 알려준다고 생각했다.

하지만 리뷰어님은 출력에 대한 클래스가 이미 존재하므로, 해당 클래스에 위임하면 어떻겠냐고 말씀하셨다.

이 부분에 대한 명확한 정답이 없겠지만, 내 방식으로 구현했을 때 한 가지 단점이 있다.

출력 형식이 변경되면 출력 클래스가 변경되는 것이 아닌, 상태를 가지고 있는 도메인 클래스가 변경된다는 점이다.

리뷰어님이 직접 경험해보고 각자의 장단점을 비교해보라고 하셨는데, 위에서 말한 단점 때문에 리뷰어님 피드백대로 출력 관련 기능은 출력에서 수행하는 것을 선호하게 되었다.

 

 

클래스 내 속성이 private이라고 좋은 건 아니다

Car 클래스의 position을 private으로 두고 싶은 나의 고집 때문에..

List<Car>에서 가장 큰 position을 구하기 위해 Car 클래스가 Comparable을 impl하는 등 복잡도가 높아졌다.

상황에 따라 외부에서 객체의 값을 직접 참조하는 것이 적절한 경우도 있다.

또한 var 프로퍼티인 position을 public으로 노출시키면 외부에서 값을 변경할 수 있는데, private set 접근자를 사용하면 해결된다.

 

 

class와 object 사용 기준

object는 프로그램 종료시까지 생명주기가 이어지기 때문에, 프로그램 종료시까지 꼭 필요한 상태가 있다면 object를 사용한다. 

또한 상태를 가지지 않는 class의 경우도 굳이 인스턴스를 여러개 생성할 필요가 없기 때문에 object를 사용한다.

 

 

모호한 함수명 지양하기

process, execute 등의 함수명은 어떤 경우에 써도 어색하지 않다.

모호한 함수명은 함수의 역할을 알아차리기 어렵고 역할이 커질 수 있다.

 

 

controller는 model, view가 어떻게 동작하는지 알 필요가 없다

controller가 model의 구현 내용을 알고 제어하는 것보다, model이 스스로 일을 하도록 설계하자.

추가적으로 나는 비즈니스 로직을 가지는 domain 패키지로 model과 service 패키지 모두 생성했는데, model에는 데이터 저장이 주된 역할인 클래스들을, service는 데이터 가공이 주된 역할인 클래스들을 담았었다. 

리뷰어님이 내가 구현한 service는 model의 로직을 서포트하는 느낌이기 때문에 controller에서 굳이 service를 알 필요가 없을 것 같다는 피드백을 해주셨다.

이후 코치님께 service는 현재 미션 규모에서는 필요없는 패키지라고 피드백을 받았고, 현재 service 패키지는 지양하고 있지만~ 앞으로도 도움이 될 것 같은, 기억에 남는 코멘트이기 때문에 일단 기록!

(model이 스스로 일을 하도록 구현하는 것이 레벨1의 목표라면, service는 정말 필요없는 것이 맞았다..)

 

 

상수는 어디에 선언해야 할까?

상수를 관련 클래스에 선언할지, 상수만 가지는 클래스를 만들지에 대해 크루들끼리 많은 이야기를 나눴다.

크루들끼리도 의견이 많이 갈리기도 했고, 리뷰어님의 생각과 현업에서는 어떤 방식이 주로 쓰이는지 궁금해서 질문을 드렸다.

리뷰어님은 관련된 클래스에 private으로 상수를 선언해주고, 필요시 외부로 꺼내는 것을 선호한다고 하셨다.

 

1. 프로그램은 작은 단위에서 점점 커지기 때문에 개발 초기부터 상수의 카테고리를 적절하게 정의하는 것이 어려움

2. (1)번의 이유로 상수의 카테고리를 넓게 잡을 수 밖에 없고, 이후 해당 클래스의 크기가 커지고 관리가 어려워짐

 

 

 

리뷰어/페어 피드백

리뷰어 피드백
- 궁금한 부분이 있을 때, 넘어가지 않고 이해가 될 때까지 논의를 이어나감

- 구현 내용의 trade-off 요소를 이해하고 적절한 선택과 이유를 잘 풀어나감
- 전반적으로 커뮤니케이션에서 막히는 부분이 없었음

 

 

페어 피드백
- 코틀린에 대한 이해도가 높고 다양한 활용 방법을 알고 있음
- 자신의 생각에 대한 근거를 들어 논리적으로 주장을 펼치는 능력

- 항상 옆에서 올바른 자세로 허리를 꼿꼿이 세우고 있는 모습

 

 

 

자동차 경주 미션을 끝내고

프리코스 2주차 때 구현했던 미션과 동일하기 때문에 혼자라면 몇 시간 안에 구현할 수 있을 것 같았다.

그래서 페어와 구현을 끝내고 첫 리뷰 요청을 보내는 기간인 3일이 굉장히 길다고 생각했다.

예상과는 다르게, 페어랑 여러 얘기를 나누면서 하다보니 시간이 꽤나 걸렸다.

혼자서는 내가 알고있던 것들이 올바르다고 생각하면서 구현을 했지만,

페어 프로그래밍에서는 내가 알고있던 것들이 꼭 정답이 아닐 수 있다고 생각했다.

페어와 여러 얘기를 하면서 사고가 넓어지는 것 같아 즐거웠던 페어 프로그래밍 😊

 

아쉬운 점은.. 페어와 나 둘다 페어 프로그래밍이 처음이고, 코드에 대한 논의를 하면서 작성하느라 Driver와 Navigator의 역할이 분명하게 나누어지지 못했다.

또한 사소한 의문들이 많아서 다른 크루들보다 구현하는데에 시간이 더 걸렸던 것 같다.

물론 의문을 많이 가지는 것은 좋지만, 사소한 것에 시간을 쏟느라 구현을 제시간에 못하면 안 되니까! 

의문 해결과 시간 분배 사이의 적절한 중간지점을 찾는 것도 굉장히 중요하다고 느꼈다.

그리고 페어인 채채가 내 의견을 많이 존중해 주었는데, (물론 채채가 내 방법이 좋다고 해주었다.. 짱채채..) 코드 관련해서는 내 고집이 강한가? 생각도 든다 ㅋㅋ 

우테코 와서 제일 많이 들은 말이 개발에 정답은 없다는 말이다. 나도 열린 마음으로 코드를 봐야겠다는 생각..

페어 프로그래밍과 코드 리뷰에서도 소프트스킬이 중요하다는 걸 느꼈다.

작년 인턴으로 근무할 때 코드 리뷰를 여러 번 받았었다.

(내가 코드를 더럽게 작성하기도 했고) 왠지 혼나는 느낌이 (;;) 들어서 질문도 잘 못 드렸다.

그런데 요즘은 모르는 부분은 바로 질문하고, 내 의견을 확실히 표현하는 것도 엄청난 소프트스킬 역량이라는 것을 느끼고 있다.

우테코에서 여러번 코드 리뷰를 받다보면 어떤 질문을 드려야 할지, 어떤 식으로 의사 소통을 할지에 대해 연습이 확실히 될 것 같다.

앞으로 페어 프로그래밍과 코드 리뷰를 하면서 여러 스타일의 사람들과 개발 얘기를 할텐데, 같이 일 하고 싶은 개발자가 되고 싶다.