[🚀 사이클1 - 미션 (블랙잭 게임 실행)] 대길 미션 제출합니다. by minzzun99 · Pull Request #1013 · woowacourse/java-blackjack

minzzun99 · 2026-03-08T07:48:11Z

체크 리스트

미션의 필수 요구사항을 모두 구현했나요?
Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
애플리케이션이 정상적으로 실행되나요?

어떤 부분에 집중하여 리뷰해야 할까요?

1. 인스턴스 변수 개수 제약에 대한 고민

이번 미션에서 인스턴스 변수 3개 이상 사용 금지라는 규칙을 지키기 위해 클래스를 최대한 세분화해 보았습니다. 각 객체가 가지는 상태는 줄어들었지만, 한편으로는 오히려 객체가 너무 많아져 전체적인 구조가 더 복잡해진 것이 아닌가하는 의구심이 들었습니다. 해당 고민에 대한 의견이 궁금합니다!

또한, 출력 로직에 데이터를 전달하기 위한 DTO를 구현할 때도 위와 같은 규칙을 적용하려다 보니 PlayerDto 내부에 ResultDto 를 필드로 가지게 된 것처럼 DTO가 DTO 객체를 포함하는 구조가 되었습니다. 데이터 전달이 목적인 DTO라면 인스턴스 변수 개수 제약에서 조금 더 자유로워도 되지 않을까 하는 생각이 들었는데 해당 부분에 대해서 리뷰어님께서는 어떤 기준을 가지고 계신지 의견은 어떠신지 궁금합니다!

2. TDD와 설계 사이의 우선순위

이번에 TDD를 처음 시도해 보면서 테스트를 먼저 작성하기 위해서는 이미 어느 정도 완벽한 설계가 머릿속에 있어야 하는 게 아닐까 싶었습니다. 또한, 설계를 고민하다 보니 결국 구현을 먼저 하게 되는 경우도 많았습니다. 리뷰어님께서는 생각하시는 TDD에 대한 의견과 TDD에 대한 팁이 있다면 듣고 싶습니다!

3. 메시지의 상수화에 대한 고민

이전에 프리코스를 진행하면서 따로 상수처리를 하는 것이 좋다는 리뷰를 받은 후 예외 메시지나 출력 문구를 모두 상수 클래스로 관리했었습니다. 이번 페어프로그래밍을 진행하면서 출력문이나 예외 메시지는 상수처리하는 것보다 오히려 그대로 두는 편이 가독성이 더 좋은 것 같다는 페어의 의견을 반영하여 메시지를 하드코딩된 문자열 그대로 두었습니다. 해당 고민에 대한 의견이 듣고 싶습니다!

4. 페어 프로그래밍과 구현 속도에 대한 고민

첫 페어 프로그래밍을 경험해보면서 의견을 조율하고 질문하는 과정에서 생각보다 많은 시간이 소요되었습니다. 네비게이터의 역할에서 페어의 의견이 궁금하기도 하고 방식이 달랐던 부분이 꽤 있다보니 너무 많은 질문을 했던 것 같기도 합니다. 페어는 괜찮다고 했지만 너무 많은 질문과 논의가 구현 속도가 늦어지는 원인이 되었다고 생각합니다. 리뷰어님만의 페어 프로그래밍 노하우나 네비게이터의 적절한 질문과 논의에 대한 기준이 있으신지 궁금합니다!

…sultDto 구현

- 딜러 카드 16이하 여부 확인 테스트 구현 - 카드 추가 확인 테스트 구현

- 플레이어의 카드 추가 여부 확인 테스트 - 플레이어의 버스트 여부 확인 테스트

- 모든 플레이어들의 버스트 여부 확인 테스트 작성

- 플레이어 이름 길이가 20자를 초과할 경우 예외 발생 테스트 작성 - Null 혹은 빈 값 입력 시 예외 발생 테스트

her0807

안녕하세요 대길!
리뷰어 수달입니다. ㅎㅎ
미션 수행하느라 고생 많으셨어요.

작성해주신 내용 토대로 제 의견 적어보았습니다.
재밌게 얘기 나눠봐요 ! ☺️

src/main/java/domain/ScoreCalculator.java

her0807 · 2026-03-09T00:17:32Z

src/main/java/domain/GameResultCalculator.java

+    public static TotalFinalResult checkGameResult(Players players, Dealer dealer){
+        return TotalFinalResult.from(players.getPlayers().stream()
+                .map(player -> checkFinalResult(player, dealer))
+                .toList());
+    }


플레이어 버스트 → 딜러 버스트 → 점수 비교 순서로 3단계 판정을 하는 구조가 블랙잭 규칙을 잘 풀어내셨네요
둘 다 버스트면 플레이어 패배라는 까다로운 케이스도 대길님은 잘 구현 하셨어요 💯

플레이어 버스트일 경우 딜러가 버스트 되어도 딜러 승으로 판정하는 로직에서 시간을 많이 썼던 것 같은데
좋게 봐주셔서 감사합니다!

src/main/java/domain/Deck.java

src/main/java/view/InputView.java

her0807 · 2026-03-09T00:20:51Z

src/main/java/dto/DealerFinalResultDto.java

+    private static String checkDrawCount(int winCount, int drawCount, int loseCount) {
+        if (drawCount > 0) {
+            return String.format("딜러: %d승 %d무 %d패%n", winCount, drawCount, loseCount);
+        }
+        return String.format("딜러: %d승 %d패%n", winCount, loseCount);
+    }
+}


딜러: %d승 %d무 %d패 같은 출력 포맷을 DTO 안에서 만들고 있는데요~ DTO 객체는 말 그대로 계층간 데이터를 전달하는 객체예요! 출력 포맷팅은 View의 책임이니까, DTO는 순수 데이터(int win, int draw, int lose)만 전달하고 포맷팅은 OutputView에서 처리하면 계층 간 책임이 깔끔해질 것 같아요. 대길님 생각은 어떠세요?

이 부분은 사실 처음 코드를 작성하면서도 고민을 많이 했었습니다!
DTO가 출력의 대한 포멧을 알게되면 DTO의 역할과 멀어지는게 아닌가 싶었는데, 수달님 덕분에 생각이 확고해진 것 같습니다!
해당 부분은 OutputViewFormatter 클래스를 추가하고, 포멧팅 로직은 전부 OutputViewFormatter에서 처리할 수 있도록 수정했습니다!
또한 기존에 OutputView에서 처리하던 포멧팅 로직도 전부 OutputViewFormatter로 옮겨서 수정했습니다!

질문

다만 한 가지 궁금한 점은 OutputViewFormatter로 포맷팅 로직을 전부 옮기면서 OutputView에는 단순한 출력 로직만 남게 되었습니다.
혹시나 이런 구조가 가독성이 떨어지진 않을지, 너무 과한 분리는 아닐지 의문이 생겼습니다.
수달님께서는 어떻게 생각하시는지 의견을 듣고 싶습니다!

좋은 고민이에요! 😊 OutputView가 단순해지는 건 오히려 좋은 신호예요. 각 클래스가 하나의 책임만 갖는다는 뜻이거든요! OutputView는 출력만, Formatter는 포맷팅만 담당하는 거죠. 단순하다고 해서 가독성이 떨어지는 게 아니라, 오히려 읽는 사람 입장에서 OutputView만 보면 어떤 순서로 출력하는지 흐름이 한눈에 보이게 돼요. 포맷팅 세부사항이 궁금하면 그때 Formatter를 보면 되고요. 클래스가 복잡해서 한 파일에서 이것저것 다 하는 것보다, 단순한 클래스 여러 개가 협력하는 구조가 유지보수하기 훨씬 편하답니다 👍🏻

her0807 · 2026-03-09T00:22:57Z

src/test/java/domain/ScoreCaculatorTest.java

+public class ScoreCaculatorTest {
+    @DisplayName("점수 계산 테스트")
+    @Test
+    void 점수_계산_테스트() {
+        List<Card> cards = List.of(Card.of(CardNumber.J, CardShape.CLOVER), Card.of(CardNumber.Q, CardShape.CLOVER));
+        assertThat(ScoreCalculator.calculate(cards)).isEqualTo(20);
+    }
+}


ScoreCaculatorTest에 테스트 케이스가 1개뿐이에요! ㅜㅜㅜ 참고로 파일명에 l이 빠진 오타(Caculator -> Calculator )도 있어요

😅 ACE를 11로 계산하는 경우, ACE를 1로 유지하는 경우, ACE 2장, 페이스카드(J/Q/K), 버스트 경계값(21, 22) 등 핵심 분기에 대한 테스트를 추가하면 로직의 안전성을 더 보장할 수 있어요! 이건 취향을 탈 수도 있는데 테스트명도 한글로 작성하면 DisplayName 없이도 의도가 바로 드러나서 좋답니다 👍🏻

아이코.. 파일명 오타는 부끄럽습니다..
해당 부분은 수정 완료헀습니다!

또한 말씀해주신대로 핵심 분기에 대한 테스트도 추가했습니다!
앞으로 테스트를 더 자세히 작성해보겠습니다!

저의 경우에는 테스트명을 한글로 작성하는게 편하기도 하고 영어 메서드 이름을 생각하는 시간이 줄어들어서 한글로 작성하는 편입니다!
저는 보통 테스트 메서드 명은 한글로 짧게 작성하고 @DisplayName을 사용해서 테스트에 대해 좀 더 자세히 설명하는 방식을 사용했었습니다!

질문

수달님이 보시기에는 테스트 메서드 이름을 한글로 명확하게 지었다면 @DisplayName까지 사용하는 것이 다소 중복되거나 불필요한 과정이라고 생각되시는지 의견이 궁금합니다! 😊

결론부터 말하면, 한글 메서드명을 쓴다면 @DisplayName은 필수는 아니에요! 다만 둘의 역할이 조금 달라요. 메서드명은 코드 레벨에서 테스트를 식별하는 용도고, @DisplayName은 테스트 실행 결과 리포트에서 사람이 읽기 좋은 설명을 보여주는 용도거든요. 예를 들어 메서드명이 에이스_두장일때_하나만_11로_계산이면 충분히 의도가전달되니까 @DisplayName 없이도 괜찮아요. 다만 메서드명이 길어지면 가독성이 떨어질 수 있으니까, 그런 경우엔 메서드명은 간결하게 하고 @DisplayName에 상세 설명을 넣는 방식도 괜찮아요. 팀 컨벤션에 따라 통일하면 되는 부분이에요 😊

src/main/java/domain/ScoreCalculator.java

her0807 · 2026-03-09T00:30:58Z

src/main/java/domain/BlackjackGame.java

+import java.util.List;
+
+public class BlackjackGame {
+    private static final int INITIAL_CARD_COUNT = 2;


메시지의 상수화에 대한 고민

제가 메세지를 상수로 변경할 때 기준은 중복 횟수와 변경 가능성이에요!

하드코딩 문자열 -> 1곳에서만 쓰이고 변경 가능성 낮을 때

클래스 내 private static final -> 같은 클래스에서 반복 사용될 때

별도 상수 클래스/Enum -> 여러 클래스에서 공유될 때

한 곳에서만 쓰이는 메시지까지 상수로 추출하면 오히려 가독성이 떨어져요. 그리고 서로 무관한 상수들이 하나의 Constants 클래스에 모이면 컴파일 시간 증가, 응집력 저하 등 문제가 생기거든요! 지금 단계에서 별도 상수 클래스까지 만드는 건 과도할 수 있으니 실용적으로 접근해보면 좋을 것 같아요 😊

페어와 이런 부분들을 얘기하며 간접경험을 통해 어떨 때 상수화하면 좋겠다! 이런 대길만의 생각들을 정리하는 시간이 페어프로그래밍의 완전 장점이라고 생각해요!! 회사가면 이렇게 고민할 시간이 엄청 적어지거든요 ㅜㅜ

상수 처리에 대한 부분은 프리코스를 진행하면서부터 계속 고민했던 부분이었습니다!

저 역시 '다른 곳에서 사용되는 문자열이 아닌데 굳이 분리를 해야되나?' 싶은 생각을 여러번 했었는데 프리코스를 진행하면서 받았던 코드 리뷰에서 문자열은 상수로 처리하는게 좋지 않겠냐는 리뷰를 그냥 맹목적으로 따랐던 것 같습니다.

상수화에 대한 부분도 상수화를 해야하는 이유나 하지 말아야할 이유를 명확히 답변할 수 있도록 열심히 고민하고 물어보면서 저만의 기준을 잡아보겠습니다!

의견 너무 감사드립니다!👍

her0807 · 2026-03-09T00:42:01Z

README.md


-블랙잭 미션 저장소
+규칙을 적용하면서 블랙잭을 구현한다.
+


페어 프로그래밍 효율에 관하여

페어의 가치는 코드 작성 속도가 아니라 지식 공유와 실수 방지에 있어요!
그런면에서 충분한 설계에 대해서 논의를 나누고, 코드를 작성하신 부분 아주 잘하셨어요.

만일 설계를 안하고 빠르게 구현을 했다면 구현을 번복하거나 수정해야하는 일이 더 많았을거라고 생각해요.
서로 만족스럽지 못한 코드가 나오면 서로 2단계에서 코드를 아예 뒤집기도 하고요 ..^^

그럼에도 속도를 내고싶다면.. 시간을 정해보는것도 좋을 것 같아요. 최대 5시간안에 구현을 끝내보자. 이런식으로요!
그리고 타이머를 켜고 시간을 정확하게 지키는 것도 중요하지만 상대방 의견이 강력하면 드라이브를 맡겨보는 것도 방법이에요. 안해본 생각과 구현을 옆에서 보는 것도 좋은 경험이 되니까요. ㅎㅎㅎ

+++ 만일 상대방을 설득하려고 했는데 그게 잘 안되었다면 대길이 의견을 주고받을 때 먼저 상대방 의견에 대해 긍정적으로 대하는 것도 좋은 방법이 될 수 있어요. 서로 라포가 생기지 않은 상황에서 반박을 지속적으로 하게되면 상대방을 공격을 받는다고 느껴서 동일하게 반박을 하게되는 경향이 있어요. 그래서 상대방에게 충분한 공감과 칭찬을 하면서.., 내 의견에도 수용적으로 대할 수 있게끔 유도해보는것도 방법일지도..!!!

그리고 추가로 페어가 끝나고 일일회고를 해보시는걸 추천드려요.

오늘 좋았던 점( 칭찬 한개)

나에게 아쉬운점 ( 본인 스스로 본인이 아쉬운점 한개 말하기)

우리의 페어 과정에서 개선하면 좋을 점 (이 때 상대방 말투가 강했다거나 스위칭 시간을 잘 안지켰다거나..요런걸 말하는거죠!)

이 얘기를 나누면서, 본인의 태도에 대해서도 스스로 돌아보고 사소하지만 페어가 상처받았을 수도 있는 부분에 대해서 먼저 언급해서 사과하고, 또 내가 마음에 담아둘만한 내용을 꺼내면서 서로 라포를 쌓을 수 있어요

강추..

이번 페어는 저의 질문이나 의견을 잘 들어주고 잘 반영해줘서 너무 편하게 진행했던 것 같습니다.

앞으로 페어 프로그래밍을 진행하면서 의견이 대립되는 경우도 있게 될텐데 말씀해주신대로 상대방의 의견을 긍정적으로 생각하면서 F의 마음가짐으로 은근슬쩍 의견을 제시해보는 방향으로 진행해보겠습니다!

페어와 회고도 꾸준히 진행하면서 부족한 점을 채워갈 수 있는 페어 프로그래밍을 한 번 만들어보겠습니다!

her0807 · 2026-03-09T00:46:27Z

src/main/java/dto/PlayerDto.java

+) {
+    public static PlayerDto from(Player player) {
+        return new PlayerDto(player.getName().getName(), ResultDto.from(player));
+    }


인스턴스 변수 3개 이하 제약과 DTO 복잡성

대길님 질문을 두 가지로 쪼개어 답변해볼 수 있을 것 같은데요! 😊

1. 제약을 따랐더니 클래스가 너무 많아져서 오히려 복잡해진 것 같아요

이 제약의 목적은 하나의 객체가 너무 많은 상태를 가지지 않게 하는 거예요! 그런데 제약을 지키기 위해 억지로 클래스를 쪼개면 오히려 전체 구조 파악이 어려워질 수 있거든요. 클래스를 분리하는 기준은 변수 개수가 아니라 **이 객체가 독립적인 책임을 가지고 있는가?**예요! 예를 들어 Hand가 카드 목록을 관리하는 건 독립적인 책임이니까 분리가 자연스럽지만, 단순히 변수 개수를 맞추기 위해 의미 없이 쪼개는 건 오히려 복잡도를 높이는 결과가 되어요. 대길님 코드는 Hand, Score, Deck 등 각 객체가 명확한 책임을 가지고 있어서 잘 분리되어 있다고 생각해요 👍🏻

2.DTO에도 이 제약을 적용해야 하나요?

DTO는 데이터 전달 목적이기 때문에 이 제약의 대상이 아니에요! PlayerDto 안에 ResultDto를 넣은 구조가 제약을 지키려다 보니 생긴 것 같은데요~ 만약 name, cards, score를 펼쳐서 담는 게 더 자연스럽다면 그렇게 해도 괜찮아요. DTO를 억지로 쪼개면 View 코드에서 playerDto.resultDto().cards() 이런 식으로 꺼내야 해서 오히려 불편해지거든요!
물론 현재 구조처럼 ResultDto로 묶는 것도 카드 정보와 점수를 하나의 결과 단위로 보면 충분히 의미 있는 설계예요. 핵심은 제약을 맹목적으로 따르는 것이 아니라, 제약의 취지를 이해하고 상황에 맞게 적용하는 것이라고 생각해요 😊

제약을 맹목적으로 따르는 것이 아닌, 제약의 취지를 이해하고 적용하는 것이라는 말씀 덕분에 그냥 이렇게 하라니까 해야지보다는 왜 요구사항을 이런걸 줬는지 이해하려 노력하고 상황에 맞게 적용하는 습관이 중요하다는 생각이 들었습니다.
맹목적으로 따라가는 코드가 아닌 이유와 기준을 가진 코드를 작성할 수 있도록 생각하는 습관이 필요할 것 같습니다.

정성스러운 코드리뷰 너무 감사드리고 수달님의 리뷰로 많은 부분 깨닫게 된 것 같습니다!
너무 감사드립니다!😎

- Card 클래스 필드 final로 변경

…r로직 적용

- ACE 카드 11 계산 로직 확인 테스트 - ACE 카드만 두 장일 경우 12 반환 확인 테스트 - ACE 카드 세 장일 경우 총 합 계산 테스트 - 카드가 없을 경우 0 반환 확인 테스트 - 카드의 합 21 초과 반환 확인 테스트

her0807

안녕하세요 대길

늦은시간까지 고생 많으셨어요.
요구사항 모두 충족된 것 같아 이만 머지할게요!
다음미션에서 만나요 :)

simhokyung and others added 30 commits March 5, 2026 12:52

docs: 블랙잭 미션 README 초안 작성

d32da74

docs(맥스): README 예외 처리 규칙 추가

ce21f2c

feat: InputView 사용자 이름 입력, 카드 추가 여부 구현

75962f0

test: 덱에 카드가 없는 경우 예외 처리 테스트 구현

d7a1d18

feat: Deck에서 카드를 뽑는 draw 메서드 구현

f70f371

feat: 참가자 이름을 파싱하는 NameParser 구현

88ff16f

feat: 카드숫자 1~10을 관리하는 Enum 구현

ee164cf

feat: 카드 모양을 나타내는 CardShape을 Enum으로 구현

4865776

feat: CardNumber(카드숫자)와 CardShape(카드모양)을 받아 관리하는 Card 구현

a9f6fb3

feat: 플레이어와 딜러가 손에 가지고있는 카드를 나타내는 도메인 구현

3af8be8

feat: 점수를 나타내는 Score 도메인 구현(원시값 포장)

b8311b7

feat: CardNumber 도메인에 Symbol 추가

f1fa65a

feat: 딜러와 플레이어가 받는 카드를 출력하는 OutputView 구현

6b70e46

feat: Dealer 도메인 구현

c7411c4

feat: 참가자를 나타내는 Player 도메인 구현

fc1a151

feat: Player 리스트를 모아놓은 Players 도메인 구현

9ca1e73

feat: GameController 뼈대 구성

9e59c62

test: 카드 점수계산 test 작성

442c944

feat: 카드 점수를 계산하는 ScoreCalculator 도메인 구현

df03b79

feat: View에 값 전달을 위한 DealerResultDto, PlayerDto, PlayersDto, PlayerRe…

fe60635

…sultDto 구현

feat: 파라미터 Dto로 변경, 카드 현황 출력 로직 및 점수 출력 로직 구현

c26fded

refactor: Scanner 중복 제거

896b284

test: Dealer 테스트 추가

75c7e6f

- 딜러 카드 16이하 여부 확인 테스트 구현 - 카드 추가 확인 테스트 구현

feat: Dealer의 카드 추가 로직 구현

26c5b86

test: 플레이어 테스트 작성

71ab035

- 플레이어의 카드 추가 여부 확인 테스트 - 플레이어의 버스트 여부 확인 테스트

feat: 플레이어의 카드 추가 로직 및 버스트 여부 확인 로직 추가

1cdc20b

test: Players 테스트 구현

9ab3080

- 모든 플레이어들의 버스트 여부 확인 테스트 작성

feat: 모든 플레이어들의 버스트 여부를 확인하는 로직 구현

f7b44e2

test: Name 클래스 테스트 작성

e95ef28

- 플레이어 이름 길이가 20자를 초과할 경우 예외 발생 테스트 작성 - Null 혹은 빈 값 입력 시 예외 발생 테스트

feat: 플레이어의 이름을 관리하는 Name 클래스 구현

a83d96c

minzzun99 and others added 21 commits March 7, 2026 17:57

feat: 전체 최종 결과 관리를 위한 TotalFinalResult 구현

0786e8f

feat: 플레이어별 최종 결과 관리를 위한 FinalResult 구현

c1cb694

feat: 승, 무, 패를 관리하는 Enum 구현

c399b48

feat: 최종 승패 결과 출력을 위한 메서드 추가

b75dd97

feat: 최종 결과 출력을 위한 컨트롤러 구현

091289a

feat: 승패 판정을 위한 GameResultCalculator 구현

48e7f1b

feat: Dealer와 Player의 공통된 메서드를 제거하기 위한 Participant 클래스 추가

9bb0cfd

feat: Player와 중복된 메서드 제거해서 다시 구현

ea79a35

feat: Dealer와 중복된 메서드 제거해서 다시 구현

33c2910

refactor: 매직 넘버 제거

14baaeb

refactor: 매직 넘버 제거

53119fc

refactor: 계산 로직 인덴트 1로 리팩토링

0337cad

test: 카드,딜러,플레이어 초기화와 게임 규칙을 가지는 Blackjack 테스트 구현

054b8a8

feat: 카드,딜러,플레이어 초기화와 게임 규칙을 가지는 Blackjack 도메인 구현

efcb0f1

feat: 딜러와 플레이어들을 관리하는 GameParticipants 도메인 구현

adcd3bc

refactor: 카드,플레이어,딜러를 초기화 하는 메서드를 Blackjack 도메인으로 옮겨 책임 분리

7e15fc9

refactor: DealerResultDto와 PlayerResultDto를 ResultDto로 변경 및 줄바꿈, 공백 제거

e0175ca

refactor: Score 클래스 Record로 변경

5c25a3c

refactor: 줄바꿈 제거 및 공백 추가

6707507

refactor: DealerFinalResultDto 내부 인덴트 제거를 위한 리팩토링

96ec568

docs: README 수정

1134e84

her0807 requested changes Mar 9, 2026

View reviewed changes

minzzun99 added 6 commits March 10, 2026 14:44

refactor: Deck 클래스 내부 Getter의 방어적 복사 적용

1c65016

- Card 클래스 필드 final로 변경

refactor: view 클래스 외부 주입 방식으로 변경

d80cb11

refactor: DTO의 출력 포멧 변환 로직을 OutputViewFormatter 클래스로 분리

f2d8b40

refactor: OutputViewFormatter 클래스 외부 주입 방식으로 변경 . OutputView Formatte…

19c75af

…r로직 적용

refactor: TotalFinalResultsDto의 출력 포멧팅 로직 제거

c6571f7

her0807 approved these changes Mar 10, 2026

View reviewed changes

her0807 merged commit bd39569 into woowacourse:minzzun99 Mar 10, 2026


		블랙잭 미션 저장소
		규칙을 적용하면서 블랙잭을 구현한다.

Conversation

minzzun99 commented Mar 8, 2026

체크 리스트

어떤 부분에 집중하여 리뷰해야 할까요?

1. 인스턴스 변수 개수 제약에 대한 고민

2. TDD와 설계 사이의 우선순위

3. 메시지의 상수화에 대한 고민

4. 페어 프로그래밍과 구현 속도에 대한 고민

Uh oh!

her0807 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

her0807 Mar 9, 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!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

minzzun99 Mar 10, 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!

minzzun99 Mar 10, 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!

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!

her0807 Mar 9, 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!

her0807 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

her0807 Mar 9, 2026 •

edited

Loading

minzzun99 Mar 10, 2026 •

edited

Loading

minzzun99 Mar 10, 2026 •

edited

Loading

her0807 Mar 9, 2026 •

edited

Loading