[자동차 경주 미션 1,2단계] 이태규 미션 제출합니다. by Cappucciyes · Pull Request #173 · next-step/java-racingcar-simple-playground

Cappucciyes · 2026-03-15T21:05:00Z

안녕하세요! 시간을 내어 리뷰해 주셔서 감사합니다.

이번 미션을 진행하면서 몇 가지 궁금한 점이 생겨 질문을 드리고 싶습니다.

이번 미션에서는 "indent(인덴트, 들여쓰기) depth를 2를 넘지 않도록 구현한다" 라는 요구사항을 신경 쓰면서 코드를 작성했습니다. 그런데 생각보다 조건이 꽤 제한적으로 느껴져서, 왜 기준이 2 depth로 설정되어 있는지 궁금해졌습니다. 예를 들어 행렬에 적용하는 이중 for문처럼 상황에 따라 충분히 자연스럽고 효율적인 코드가 나올 수 있다고 생각하는데, 이러한 기준이 있는 이유가 무엇인지 알고 싶습니다.
테스트 코드를 작성하면서 테스트를 더 편하게 만들기 위한 메서드를 추가하고 싶다는 생각이 들었습니다. 하지만 이런 메서드가 테스트를 위한 목적에만 사용된다면, 실제 코드 품질에 도움이 되는지 아니면 오히려 코드의 의도를 흐릴 수 있는지 궁금합니다.
예를 들어 Race 클래스의 테스트를 작성하면서, Race 객체가 관리하는 모든 Car 인스턴스의 이름과 현재 distance를 반환하는 메서드가 있으면 테스트를 작성하기 편하겠다고 느꼈습니다. 이런 방식이 괜찮은 접근인지 의견을 듣고 싶습니다.

이외에도 개선하면 좋을 부분이 있다면 편하게 말씀해주시면 감사하겠습니다.

type(scope): subject

@OverRide

- 생성자가 더이상 인자를 받지 않도록 수정 - 그 외 코드 가독성을 위해 @OverRide 추가

type(scope): subject

- race의 racers가 비어었을 때 getCurrentWinners()가 비어있는지 확인

70825

안녕하세요 태규님! 저도 잘 부탁드립니다 🙇‍♂️ 첫 미션 화이팅이에요!

기술적인 코드 리뷰의 경우에는 AI가 더 잘해주기 때문에 제가 이야기하는 것보다 AI 활용하시는게 좋아보여서 태규님의 생각을 물어보는 질문들 위주로 남겼어요

이번 미션에서는 "indent(인덴트, 들여쓰기) depth를 2를 넘지 않도록 구현한다" 라는 요구사항을 신경 쓰면서 코드를 작성했습니다. 그런데 생각보다 조건이 꽤 제한적으로 느껴져서, 왜 기준이 2 depth로 설정되어 있는지 궁금해졌습니다. 예를 들어 행렬에 적용하는 이중 for문처럼 상황에 따라 충분히 자연스럽고 효율적인 코드가 나올 수 있다고 생각하는데, 이러한 기준이 있는 이유가 무엇인지 알고 싶습니다.

요거는 제약조건이 어렵긴한데 좋은 코드를 만들기 위한 연습이라고 생각하시면 됩니다. 개발에서 좋은 코드란 유지보수하기 쉬운 코드인데요. 유지보수하기 좋은 코드란 아직까지는 사람이 코드를 관리하기 때문에 읽기 쉬운 코드가 중요합니다
읽기 쉬운 코드는 저는 '큰 생각 없이 읽을 수 있는 코드'라고 생각해요. 그런 의미에서 이중 for문의 경우에는 첫 for문을 기억하면서 두번째 for문까지 기억해야하는 이해하는데 비용이 비싼 코드라고 생각합니다
요즘은 컴퓨터 기술이 발전해서 서비스 개발의 경우에는 성능보다는 가독성이 중요하다고 생각하는게 정석이 된 것 같아요 그래서 어떻게하면 더 가독성 있는 코드가 될지에 대한 연습도 되는 목적이 있다고 생각합니다.

추가적으로 객체지향에 SOLID 법칙이라는게 있는데, 그중에 S인 단일 책임 원칙을 만족하는지에 대한 내용도 포함되어 있다고 생각해요. 자바 미션이 어떻게하면 객체지향적인 코드를 만들 수 있는지에 대한 고민을 많이하는 미션이기 때문에 객체지향쪽도 잘 고민해서 적용해보시길 바래요~

테스트 코드를 작성하면서 테스트를 더 편하게 만들기 위한 메서드를 추가하고 싶다는 생각이 들었습니다. 하지만 이런 메서드가 테스트를 위한 목적에만 사용된다면, 실제 코드 품질에 도움이 되는지 아니면 오히려 코드의 의도를 흐릴 수 있는지 궁금합니다. 예를 들어 Race 클래스의 테스트를 작성하면서, Race 객체가 관리하는 모든 Car 인스턴스의 이름과 현재 distance를 반환하는 메서드가 있으면 테스트를 작성하기 편하겠다고 느꼈습니다. 이런 방식이 괜찮은 접근인지 의견을 듣고 싶습니다.

요거는 태규님이 생각하는 테스트 코드의 목적과 일반적인 테스트 코드의 목적과 어긋나는게 있어보이는데요

테스트 코드의 목적은 "기능이 잘 동작하는가?"입니다. 모든 데이터를 들여다보는게 쉽고 빠른 길이긴한데 😁, 결국 서비스란 메서드를 통해서 데이터를 제공하므로 태규님이 만든 메서드가 의도대로 잘 동작하는지가 중요한 것 같아요

70825 · 2026-03-16T13:52:21Z

+    }
+
+    public void move() {
+        int flag = numberGenerator.generateNumber();


일반적으로 flag는 true / false에 쓰이는 용도의 변수라서 변수명을 바꾼다고하면 어떤 변수명이 더 좋을까요?

변수명을 바꾸자면 currentNumber나 generatedNumber 등이 좋을 것 같다는 생각이 드네요.

솔직히 위 질문을 읽고 생각했을 때, 메소드 자체가 특정 상황에서 (numberGenerator.generateNumber() >= 4 일 때) 자동차를 이동시키는 메소드 이기에, 변수를 boolean 으로 쓰는게 더 좋겠다는 생각 이 들어 변수를 다음과 같이 바꿨어요.

boolean canMove = numberGenerator.generateNumber() >= 4;

70825 · 2026-03-16T13:54:24Z

+    private int distance = 0;
+    private String name;
+    private NumberGenerator numberGenerator;


값이 바뀌지 않는 부분은 final을 명시하는 것도 좋아보여요
불변성에 대해 찾아보시면 좋습니다~

확실이 final을 명시하는게 협업이나 코드 이해에 도움이 많이 될 것 같네요. 참고하겠습니다.

70825 · 2026-03-16T14:04:20Z

+    Car testCar;
+    @BeforeEach
+    public void setupTest() {
+        this.testCar = new Car("TestCar", new TestNumberGeneratorImpl());
+    }


여기 영역의 코드를 추가했을때 장단점은 무엇이 있다고 생각하시나요?

매 테스트를 동일한 환경(지금 같은 경우 새로운 인스턴스)을 사용한다는 점이 강력한 장점인 것 같습니다. 테스트 코드를 작성했을 때 오로지 하나의 기능을 검사하는 것에 충실해야한다고 보는데, @beforeeach와 같은 효과를 주기 위해서는 반복되는 코드가 많아 지더라고요. 불필요하게 반복되는 코드를 줄여준다는 장점도 있는 것 같습니다.

단점으로서 와닫는 것은 아직 모르겠습니다. 고민을 좀 해본다면 @beforeeach 메소드가 너무 길어지거나 작업이 오래 걸리면 테스트실행이 다소 무거운 작업이 될 수 있겠다는 점이 있네요.

혹시 리뷰어님이 생각하는 또는 제가 알면 좋을 것 같은 장단점이 어떤게 있나요?

장점은 저도 똑같이 생각해서 더 알려드릴만한 내용은 없어보여요. 그런데 단점의 경우에는 지금 미션에서는 태규님 코멘트처럼 메서드가 길면 (setUp 메서드) + (테스트를 진행하는 메서드) 두 영역을 봐야하니 읽기 어려워진다는 점이 있을 것 같아요. 거기다가 setupTest를 통해 간단하게 데이터 세팅이 가능하지만, 나중에 좀 더 복잡한 미션에서는 BeforeEach로 해결하기 힘들 수도 있어보이네요

70825 · 2026-03-16T14:05:02Z

+    @Test
+    public void testCarMovesForwardProperly() {
+        for (int i = 0; i < 5; i++) {
+            testCar.move();
+            Assertions.assertEquals(max(3, i) - 3, testCar.getDistance());
+        }
+    }


5번이나 움직이면서 테스트하는 이유가 있을까요?_?

처음 3번은 distance가 0인 것을 확인하기 위해,
마지막 2번은 distance가 1씩 증가하는 것을 확인하기 위해 총 5번 움직였어요.

조금 과한 감이 없지 않아 있었나요...?

음 0과 1 모두 확인하기 위해 접근한 것은 좋지만, 5번이나 테스트하는건 비효율적인 감이 있긴해요. 제가 효율적인거 좋아해서 그럴지도요 ㅋㅋㅋ

참고로 0을 테스트할 때, 1을 테스트 할 때는 영역을 구분해서 나눠주는 것도 좋습니다

@Nested class getDistance_테스트 { @Test public void 랜덤값이_4_미만으로_나오면_자동차는_움직이지_않는다() { // given Car testCar = new Car("TestCar", new TestNumberGeneratorImpl(3)); // when testCar.move(); // then assertThat(testCar.getDistance()).isZero(); } @Test public void 랜덤값이_4_이상으로_나오면_자동차는_움직이지_않는다() { // given Car testCar = new Car("TestCar", new TestNumberGeneratorImpl(4)); // when testCar.move(); // then assertThat(testCar.getDistance()).isOne(); } }

클래스/메서드 명은 대충 적었는데, 이런 방식으로 어떤 상황인지, 어떤 값을 예상하는지를 적어두면 목적이 명확하니 좋아요

그래서 given / when / then 도 간단한 방식인데 찾아보시면 좋아보입니다

예시를 보면 테스트가 약간 빈약하다는 느낌을 지울 수가 없네요. 아무래도 확인해야 하는 것은 distance가 1씩 증가하는 것이라 생각하기에, 단순히 메소드 실행 이후 예상 값을 확인하는 것만으로도 충분한 테스트가 되는지 조심스럽게 여쭤봅니다.

하지만 질문과 별개로, given / when / then 방식이 확실히 직관적인 테스트 작성법인 것 같습니다. 앞으로 참고하겠습니다.

네 테스트 코드는 메서드가 의도한 방향으로 동작하는지 확인하는 것이기 때문에 케이스별로 한 번만 테스트하면 됩니다
같은 메서드를 여러번 테스트하는데 결과물이 다르다면 그건 문제가 있는 코드이지요

70825 · 2026-03-16T14:06:25Z

+    public void simulateSingleRound() {
+        for (Car racer: this.racers) racer.move();
+    }


Suggested change

public void simulateSingleRound() {

for (Car racer: this.racers) racer.move();

}

public void simulateSingleRound() {

for (Car racer: this.racers) {

racer.move();

}

}

들여쓰기 전반적으로 챙겨주시면 코드 읽기 더 편할 것 같아요

70825 · 2026-03-16T14:08:09Z

+        if (this.racers.isEmpty()) {
+            return new ArrayList<String>();
+        }


racers가 비어있는지 체크하는 코드를 만든 이유가 있을까요??

이건 stream API를 공부하면서 언젠가 "비어있는 stream을 사용하면 정의되지 않은 값을 반환할 수 있다"는 말을 봐서 안전하게 racers가 비어있는지 체크하는 코드를 적었어요.

이는 조금 더 찾아보니, 굳이 그렇게 할 필요가 없다는 것을 알게 되었네요...

오호 벌써 stream API까지 공부하시다니 빠르시군요
앞으로 stream API 사용할 일이 많아서 좋습니다 👍

70825 · 2026-03-16T14:09:30Z

@@ -0,0 +1,11 @@
+import java.util.Random;
+
+public class NumberGeneratorImpl implements NumberGenerator {


Impl 이라는 네이밍을 붙인 이유가 있는지 궁금해요 (= 많고 많은 네이밍중에 Impl을 선택한 이유)

인터페이스를 통한 구현체를 만들면 어떤 장점이 있다고 생각하시나요??

이는 인터페이스를 공부했을 때, 구현된 클래스의 예시 클래스명이 ~Impl 형식인것을 많이 봐서 이렇게 작성한 것 같습니다. 특히 현재 프로그램에서 사용되는 NumberGenerator는 하나밖에 없기에 NumberGeneratorImpl라 명명했습니다.

인터페이스를 활용하면 원하는 형태의 구현 방식을 적용할 수 있다는 것이 큰 장점인 것 같습니다. 역할은 동일하되 조건에 따라 다른 방식의 구현이 요구될 때, 새로운 클래스를 작성한 뒤 해당 클래스와 호환되게 모든 연관된 코드를 수정하게 되는데, 인터페이스를 활용하면 동일한 상황에서 인터페이스의 다른 구현체를 작성하기만 하면 됩니다. 저도 테스트를 작성할 때, 예측이 가능한 NumberGenerator가 필요하다고 생각해 0~9까지 차례대로 반환하는 TestNumberGeneratorImpl를 구현하였죠.

아하 이거는 큰 의미를 둔 코멘트는 아니구 한번쯤은 고민해보면 좋아보여서요. 저는 팀에서는 Impl을 접미사로 안쓰고 Default를 접두사로 쓰는 편이라서요

그러면 추가로 궁금한 점이 만약 TestNumberGeneratorImpl 같이 테스트용 클래스가 없고, NumberGeneratorImpl 하나만 사용하는 클래스가 있다면 이거는 인터페이스를 만드는게 좋다고 생각하시나요?? 여기에 대한 생각이 궁금해요

2번에 대한 답변으로는 객체의 목적과 프로젝트의 규모에 따라 답변이 달라질 것 같아요. NumberGenerator의 목적은 상태(속성)을 따로 관리할 필요 없이 오로지 특정 행동에 대한 정의를 하는 것이기에 만일 그 행동이 명확히 정의되어 있는 경우, 굳이 인터페이스를 필요로 하지 않을 것 같네요. 하지만 그런 상황에도 불구하고 만일 지금 예제보다 더 큰 프로젝트를 한다고 가정하면 (아니면 해당 프로그램의 확장성을 고려한다면), 나중을 위해서라도 인터페이스를 적용하는 것이 좋겠다는 생각이 듭니다.

좋습니다 👍

70825 · 2026-03-16T14:13:08Z

+import java.util.*;
+
+public class Race {
+    private final List<Car> racers;


요거는 지금 단계에서 어려울 수도 있는 내용인데, 일급 컬렉션에 대해 찾아보시면 좋아보여요
일급 컬렉션을 적용한다고 하면 어떤 메서드를 일급 컬렉션에서 구현할 수 있어보이나요?

리뷰 보고 나름대로 일급 컬렉션을 활용하여 코드를 재구성해보았습니다. 가능하시다면 새로 작성한 Cars 클래스에 대한 리뷰 부탁드려도 될까요?

Cappucciyes · 2026-03-18T12:10:47Z

리뷰 감사합니다. 피드백을 반영하여 코드를 수정해봤어요.

수정하면서 몇 가지 궁금한 점이 생겨 여쭤보고 싶습니다.

Python의 튜플이나 C++의 pair처럼 여러 타입의 값을 함께 묶어 반환하는 방법에 대해 고민했습니다. 찾아보니 Record를 활용하는 방식이 있어 적용해보았는데, 이 외에 Java에서 일반적으로 많이 사용하는 패턴이나 추천하시는 방식이 있을지 궁금합니다.
일급 컬렉션을 학습하고 적용해보면서, 책임의 범위에 대해 고민하게 되었습니다. 컬렉션을 안정적으로 관리하거나, 특정 도메인 규칙을 강제하고 싶을 때 일급 컬렉션이 유용하다는 점은 이해했습니다.

제가 이해한 바로는, 일급 컬렉션의 목적은 다음과 같다고 생각이 드는데요:
- 객체의 묶음을 외부에 의존하지 않고 하나의 클래스로 묶어, 도메인 규칙과 제약을 함께 관리하는 것
- 이 과정에서 생성/추가/삭제 등의 책임이 해당 클래스에 집중
다만, Race처럼 Car를 관리하면서 동시에 전진 로직과 결과 계산까지 담당하는 것이 자연스러운 경우,
이 책임을 굳이 일급 컬렉션으로 분리하는 것이 더 좋은 설계인지에 대해 고민이 됩니다.

또다시 시간을 내주어 읽어주셔서 감사합니다.

70825

안녕하세요 태규님 몇가지 코멘트 남겼습니다

Python의 튜플이나 C++의 pair처럼 여러 타입의 값을 함께 묶어 반환하는 방법에 대해 고민했습니다. 찾아보니 Record를 활용하는 방식이 있어 적용해보았는데, 이 외에 Java에서 일반적으로 많이 사용하는 패턴이나 추천하시는 방식이 있을지 궁금합니다.

오호 자바에서는 처음 보는 방식이긴한데, 저는 회사에서는 코틀린을 쓰는데 Pair를 사용하고 있긴해서 익숙해 보이긴해요

근데 저라면 getCurrentWinners, getMaxScore가 Cars에서 계산해서 결과값만 반환해주면 Cars 객체가 더 주도적으로 활동할 수 있고, RacerInfo라는 객체를 만들지 않아도 되니 더 나아보여요

Race 클래스에서는 return this.racers.getCurrentWinners()로만 사용하거나, List를 반환해서 Race에서 추가적으로 이름만 가져오도록 코드를 추가할 수도 있겠네요

일급 컬렉션을 학습하고 적용해보면서, 책임의 범위에 대해 고민하게 되었습니다. 컬렉션을 안정적으로 관리하거나, 특정 도메인 규칙을 강제하고 싶을 때 일급 컬렉션이 유용하다는 점은 이해했습니다. 제가 이해한 바로는, 일급 컬렉션의 목적은 다음과 같다고 생각이 드는데요:
* 객체의 묶음을 외부에 의존하지 않고 하나의 클래스로 묶어, 도메인 규칙과 제약을 함께 관리하는 것
* 이 과정에서 생성/추가/삭제 등의 책임이 해당 클래스에 집중
다만, Race처럼 Car를 관리하면서 동시에 전진 로직과 결과 계산까지 담당하는 것이 자연스러운 경우, 이 책임을 굳이 일급 컬렉션으로 분리하는 것이 더 좋은 설계인지에 대해 고민이 됩니다.

태규님이 작성한 일급 컬렉션 목적이 맞습니다. 일급 컬렉션이 객체지향에서 좋은 역할을 하게 되는데, 객체가 주도적으로 활동할 수 있게 됩니다
(객체가 주도적으로 활동을 한다 = 객체지향 설계가 잘 되었다 = 언제든지 다른 곳에서 재사용이 가능하다 = 확장성 있는 설계가 가능하다)
경기장(Race)이 자동차 우승자를 구하는 것보다 자동차들(Cars)이 우승자를 구하는게 좀 더 객체가 스스로 주도적으로 활동하는 것으로 보입니다

일급 컬렉션이 필요 없는 상황은 제가 생각하기엔 일급 컬렉션 안에 둬야할 도메인 규칙이 없는 상황일 때라고 생각해요

Race: 게임을 전체적으로 진행
Cars: 여러대의 자동차가 모여야지만 할 수 있는 활동들을 진행
Car: 자동차 1개로만 할 수 있는 활동들을 진행

지금은 이렇게 구분할 수 있는 상황에서는 일급 컬렉션을 적용하는게 좋아보여요

현재 코멘트랑 아래 추가적으로 코멘트 둔 내용에서 객체가 스스로 활동하는 것에 초점이 맞춰져 있는데요. 자바 공부하실 때 객체지향의 사실과 오해 책도 읽어보는걸 매우 추천드립니다. 객체지향에서 엄청 유명한 책이에요

70825 · 2026-03-18T14:04:32Z

+    public boolean addCar(Car newCar) {
+        return racers.add(newCar);
+    }


이거는 중요한 내용은 아니지만 고민해보면 좋아보여요

addCar는 이미 Car라는 값만 들어가게 되는데 add'Car'라고 붙일 이유가 있을까요?? add는 어떤가요??

요거는 팀에서도 스타일이 나뉘긴하는데 저는 add 쪽이긴해요

저는 메소드 명을 단순히 add로 하면 너무 범용적인 메소드 같다는 생각이 들어 왠만하면 무었을 더하는지 메소드명에 적는 편입니다... 특히 이 클래스의 인스턴스를 가리키는 변수가 .add()를 호출할 때, 이 변수가 원래 자바의 List인지 햇갈리는 것 같아요.

70825 · 2026-03-18T14:08:09Z

+    public void simulateSingleRound() {
+        for (Car racer: this.racers) {
+            racer.move();
+        }
+    }


이거는 의존성을 생각해보면 좋아보여요

public class Race { private final Cars racers; Race(Cars racers){ this.racers = racers; }

Race는 racers가 없으면 게임 진행이 안되니 Race는 Cars를 의존하고 있습니다
그런데 Cars는 Car만 의존하고 있어서 Race의 존재 여부를 전혀 모릅니다

Cars가 혼자 주도적으로 움직이는 객체라고 생각 했을 때(의인화 했다고 가정), simulateSingleRound라는 네이밍은 Cars가 Race라는 객체를 모르니 메서드명만으로는 무슨 행동을 하는지 모를거라고 생각해요

그래서 어떤 네이밍이 나을지 고민해보면 좋아보입니다

Cappucciyes · 2026-03-19T15:37:38Z

좋은 리뷰 감사드립니다. 이번 리뷰에서 가장 기억에 남는 피드백은 "객체는 조금 더 주도적이여야한다" 인 것 같아요. 이 생각을 가지고 코드를 다시 한번 손봤습니다. 확실히 Cars를 통해 Car들을 관리하고 상태에 대해 집계하는 것이 훨씬 더 확장성이 높은 설계인 것 같습니다.

테스트 코드 역시 리뷰를 반영해 수정해보았지만, 테스트의 범위와 엄격함의 수준에 대해서는 한 번 더 고민해볼 필요가 있겠다는 생각이 들었습니다. 이와 관련된 코멘트를 여기 에 남겼는데, 의견을 주시면 감사하겠습니다.

다시 한 번 시간을 내주어 리뷰를 해주셔서 감사합니다.

70825

코드도 깔끔해졌고 이번 단계에서 리뷰할 내용은 없는 것 같아서 이만 머지하겠습니다
고생하셨어요~ 다음 미션도 화이팅입니다~!! 🥳🥳

70825 · 2026-03-20T13:53:27Z

+    public String getName() {
+        return this.name;
+    }
+
+    public int getDistance() {
+        return this.distance;
+    }


참고로.. 인텔리제이 사용하신다면 맥북 기준으로는 Cmd+N을 통해서 필요한 getter도 빠르게 만들 수 있고, 위에 내용들 모두 빠르게 생성 가능합니다

꿑팁 감사합니다~

Cappucciyes added 14 commits March 15, 2026 01:14

docs:readme 추가

e229ba0

type(scope): subject

feat : Car, NumberGenerator, NumberGeneratorImpl 구현

78aca14

feat : Car 클래스의 name 필드 및 getter 추가

0f6a3da

refactor: Car클래스의 distance 속성 private으로 변환 후 getter 작성

a4a635b

moving machine

3eff12e

refactor : TestNumberGeneratorImpl 수정

fd01f53

- 생성자가 더이상 인자를 받지 않도록 수정 - 그 외 코드 가독성을 위해 @OverRide 추가

test: 자동차 이름 관련 테스트 추가

63c7c42

type(scope): subject

docs : 2단계 readme 업데이트

5ec801b

feat : Race 클래스 구현 및 테스트 작성

61508dc

test : TestNumberGeneratorImpl을 특정 숫자부터 시작하도록 수정

d19ce4c

test : testRace 수정 및 testSimulateSingleRound 추가

83670c3

refactor : Race의 getCurrentWinners()를 요구사항에 맞게 수정

74f7e13

test : RaceTest의 testRace() 수정

a3a6e4c

- race의 racers가 비어었을 때 getCurrentWinners()가 비어있는지 확인

style : 불필요한 import 삭제

731082a

Cappucciyes changed the title ~~[자동차 경주 미션 1,2단계] 김하은 미션 제출합니다.~~ [자동차 경주 미션 1,2단계] 이태규 미션 제출합니다. Mar 15, 2026

70825 reviewed Mar 16, 2026

View reviewed changes

Cappucciyes requested a review from 70825 March 17, 2026 12:52

Cappucciyes marked this pull request as draft March 17, 2026 12:53

Cappucciyes marked this pull request as ready for review March 17, 2026 12:53

Cappucciyes and others added 7 commits March 18, 2026 02:55

wip: trying to implement Cars

7d7b651

refactor : implemented Cars (Collection of Car instance)

0c1262b

test : added test for Cars

79e28ca

chore : 변수명 수정

f063493

refactor: changed class name Pair into RacerInfo

455d380

quick fix for car constructor

2f32457

removed default Race contstructor (Race constructor with no arguments)

daa6384

70825 reviewed Mar 18, 2026

View reviewed changes

refactor : Cars now calculate winner

05ec1f5

70825 approved these changes Mar 20, 2026

View reviewed changes

boorownie merged commit c8dfd49 into next-step:cappucciyes Mar 20, 2026

		@@ -0,0 +1,11 @@
		import java.util.Random;

		public class NumberGeneratorImpl implements NumberGenerator {

Conversation

Cappucciyes commented Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

70825 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Cappucciyes Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Cappucciyes Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Cappucciyes commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

70825 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Cappucciyes commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

70825 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Cappucciyes commented Mar 15, 2026 •

edited

Loading

Cappucciyes Mar 19, 2026 •

edited

Loading

Cappucciyes Mar 18, 2026 •

edited

Loading

Cappucciyes commented Mar 18, 2026 •

edited

Loading

Cappucciyes commented Mar 19, 2026 •

edited

Loading