3단계 - 자동차 경주 #5736
3단계 - 자동차 경주 #5736
Conversation
|
|
||
| public class Car { | ||
|
|
||
| private int position = 0; |
There was a problem hiding this comment.
Nit: Car 인스턴스 생성 시 자동으로 0으로 초기화되니 명시적으로 초기화하지 않아도 될 것 같습니다.
|
|
||
| private int position = 0; | ||
|
|
||
| public int move(int randomNum) { |
There was a problem hiding this comment.
객체지향 생활 체조 원칙 중 규칙 5: 줄여쓰지 않는다(축약 금지).를 참고해주세요.
| private int position = 0; | ||
|
|
||
| public int move(int randomNum) { | ||
| if (randomNum >= 4) { |
There was a problem hiding this comment.
숫자 리터럴 4를 하드 코딩하는 대신에 상수로 선언하여 의미를 명확하게 전달해보면 어떨까요?
|
|
||
| import java.util.Scanner; | ||
|
|
||
| public class InputView { |
There was a problem hiding this comment.
상태가 없고 정적 메서드만을 포함하는 클래스이니, 인스턴스를 생성할 필요 없이 직접 사용이 가능하겠습니다만
누군가는 실수로 인스턴스를 생성할 수도 있으니, private 생성자 등을 통해 불필요한 인스턴스화를 막아보면 어떨까요?
|
|
||
| public class InputView { | ||
|
|
||
| private static final Scanner scanner = new Scanner(System.in); |
There was a problem hiding this comment.
static final을 통해 상수로 선언하셨으니, 이름을 대문자로 작성해보면 어떨까요?
| private static final Scanner scanner = new Scanner(System.in); | |
| private static final Scanner SCANNER= new Scanner(System.in); |
| this.roundNum = roundNum; | ||
| } | ||
|
|
||
| public void start() { |
There was a problem hiding this comment.
Racing 클래스는 핵심 비즈니스 로직을 수행하는 도메인 클래스로 보이는데, 내부에서 콘솔에 값을 출력하는 view와 관련된 로직을 수행하고 있어서 도메인이 view에 의존하는 구조로 보입니다. 도메인이 view에 의존할 경우 어떤 문제점이 있을까요?
| // 첫 번째 라운드는 무조건 강제로 전진 | ||
| System.out.println(LINE + "1 라운드 시작!" + LINE); | ||
| playFirstRound(); |
There was a problem hiding this comment.
첫 번째 시도에서 반드시 자동차가 전진해야 한다는 요구사항은 없지 않나요?
| for (int i = 0; i < position; i++) { | ||
| sb.append("-"); | ||
| } |
There was a problem hiding this comment.
반복문 대신에 Racing에서 처리하신 것처럼 String의 repeat()를 활용해보시면 좋을 것 같습니다.
|
|
||
| @ParameterizedTest | ||
| @MethodSource("randomNum") | ||
| @DisplayName("자동차가 이동하는 값이 4 이상일 경우에만 전진하고 그렇지않으면 멈춰있는지 확인") |
There was a problem hiding this comment.
위에서 각 경우에 대한 자동차 전진 여부 테스트를 잘 작성해주신 것 같은데, 해당 테스트를 추가하신 이유가 있으실까요?
There was a problem hiding this comment.
언제 테스트 코드를 짜야하고 언제 커밋을 나눠야하는지 잘 모르겠습니다.. 우선 todo에 적힌걸 기반으로 커밋을 올리기는 했지만, 막상 프로덕트 코드를 짜면서 거의 어느정도 진행하다가 중간중간 테스트 코드를 짜고 커밋을 했어서 스스로 이게 아닌거같은데.. 라는 생각을 하기도 했습니다 ..
혹시 TDD 사이클에 따라 미션을 진행 중이시라면, 저라면 사이클에 따라 다음과 같이 커밋을 작성해볼 것 같아요.
- 실패하는 테스트를 작성(컴파일 에러까진 해결)하고 커밋
- 해당 테스트가 통과하도록 프로덕션 코드를 작성하고 커밋
- 해당 프로덕션 코드를 리팩토링하고 커밋
아직 TDD가 익숙하지 않으시다면 지금처럼 TO-DO 리스트의 요구사항 하나를 만족하는 코드를 작성한 이후에 커밋을 하셔도 좋습니다. 물론 이전에 커밋했던 내역도 다시 되돌릴 수 있으니, 커밋 단위가 크다고 생각되시면 다시 작은 단위로 나누는 연습을 반복적으로 해보시면 좋을 것 같습니다.
언제 테스트 코드를 짜야하고 언제 커밋을 나눠야하는지 잘 모르겠습니다.. 우선 todo에 적힌걸 기반으로 커밋을 올리기는 했지만, 막상 프로덕트 코드를 짜면서 거의 어느정도 진행하다가 중간중간 테스트 코드를 짜고 커밋을 했어서 스스로 이게 아닌거같은데.. 라는 생각을 하기도 했습니다 ..