[우테코 8기 - 레벨1] 5주차 회고

✅ 장기 사이클1: 사전학습

---

목적	키워드
게임 구현	장기 규칙, 보드 구조(9x10), 기물 종류, 초기 배치
상태 모델링	불변 객체, 방어적 복사
이동 규칙 구현	기물별 이동 방식(차, 마, 상, 사, 장, 포, 졸)
다형성	인터페이스, 추상 클래스, 오버라이딩

 

본격적인 활동에 앞서 먼저 위의 키워드들에 대해서 가볍게 공부해보고 다음의 4가지 실험을 했다.

• 실험1: 보드 초기화 설계
  • 장기판은 어떤 자료구조로 표현할 것인가?
  • 기물은 어떤 정보를 가지는가?
  • 위치 정보는 누가 관리하는가? (보드? 기물?)
  • 빈 칸은 어떻게 표현하는가?
• 실험2: 상태 분류
  • 상태가 변할 때 누가 변경하는가?
  • 상태가 외부에 노출되어도 괜찮은가?
  • 상태가 잘못 변경되면 어떤 문제가 생기는가?
• 실험3: 기물 이동시 조건문 폭발
  • 기물 종류 개수는?
  • 각 기물별 이동 규칙 개수는?
  • 예상되는 조건문 개수는?
  • 가장 복잡한 기물의 이동 규칙은?
• 실험4: 확장의 어려움
  • 새 기물 추가 시 수정해야 하는 곳은?
  • 기존 기물 규칙 변경 시 영향 범위는?
  • 조건문이 한 곳에 모여 있으면 생기는 문제는?
  • 조건문 없이 이동 규칙을 처리하는 방법은?

😃 Liked (좋았던 점)

• 무빙 크루와 장기판을 표현할 자료구조를 의논하면서 혼자 고민할 때는 놓쳤던 부분들을 잡을 수 있어서 좋았다.
• 실제 구현에 들어가기 전에 사전 학습을 통해 다양한 상황을 미리 실험해볼 수 있었던 점이 인상적이었다. 단순히 구현부터 시작했다면 놓쳤을 부분들까지 미리 인지할 수 있었고, 덕분에 더 깊이 있게 문제를 이해할 수 있었다. 

 

☹️ Lacked (부족했던 점)

• 답이 없는 문제를 너무 오래 혼자 고민했다. 

 

🧐 Learned (배운 점)

• 처음에는 장기판의 자료구조를 단순히 “장기판은 2차원 배열처럼 생겼으니, 2차원 배열로 구현하는 것이 자연스럽겠다”라고 생각했다. 하지만 Map<위치, 기물> 형태로도 충분히 표현할 수 있다는 것을 보면서, 어떤 객체를 추상화할 때 반드시 그 물리적인 모습을 그대로 코드로 옮기는 것만이 정답은 아니라는 점을 깨달았다. 
• 개발을 공부하다 보면 하나의 정답으로 결론 내리기 어려운 경우가 많다. 장기판의 자료구조를 고민했던 경험이 그 대표적인 예였다. 이런 문제를 혼자만 고민하기보다는 다른 사람과 함께 의견을 나누는 것이 훨씬 도움이 된다는 것을 다시 한번 느끼게 되었다.

 

🤗 Longed for (앞으로 바라는 점)

• 특정 문제가 30분이상 고민된다면 바로 다른 크루와 의논하자!

 

✅ 장기 사이클1: 토론

---

사전학습한 내용을 기반으로 다음 주제로 크루들과 토론하는 시간을 가졌다

1. 위치 정보는 보드가 가지는가, 기물이 가지는가?
2. 기물 객체는 불변이어야 하는가?
3. 보드의 상태를 외부에서 직접 수정할 수 있어야 하는가?
4. 빈 칸은 null인가, 객체인가?
5. 조건문은 언제 문제가 되는가?
6. 다형성으로 대체할 수 있는 조건문의 기준은?
7. 기물은 자신의 이동 규칙을 알아야 하는가?
8. 공통 인터페이스는 어떻게 설계하는가?

😃 Liked (좋았던 점)

• 하나의 주제에 대해 다양한 의견을 들을 수 있어 좋았다.
  예를 들어, 장기판을 Map으로 관리한다는 점에는 모두 공감했지만, 보드의 빈칸을 어떻게 처리할지에 대해서는 서로 다른 의견이 있었다. 어떤 크루는 빈칸까지 Map에 포함시키는 것이 좋다고 했고, 나는 Map에 존재하지 않는 key를 조회했을 때 빈칸으로 간주하는 방식이 더 적절하다고 생각했다.

 

☹️ Lacked (부족했던 점)

• 내 생각을 충분히 명료하게 정리해 전달하지 못한 부분이 있었던 것 같다. 급한 마음에 머릿속에 있는 생각을 정리하지 않은 채 이야기하다 보니, 전달 과정에서 말이 꼬이고 더듬게 되었다.

 

🧐 Learned (배운 점)

• 생각을 정리한 뒤 차분하게 전달하는 것이 중요하다는 점을 느꼈다.
• 공통 인터페이스를 설계할 때 추상 클래스와 인터페이스를 언제 사용하는 것이 적절한지 토론을 통해 정리할 수 있었다.
  인터페이스는 역할 중심의 설계와 유연한 확장이 필요할 때, 추상 클래스는 공통 상태와 기본 구현을 공유해야 할 때 사용하는 것이 적절하다는 점을 이해하게 되었다.

 

🤗 Longed for (앞으로 바라는 점)

• 생각을 정리한 뒤 말하는 습관을 가져야겠다고 느꼈다. 바로 정리가 어렵다면, 잠시 양해를 구하고 정리한 뒤 이야기하는 것이 더 효과적일 것 같다.

 

✅ 장기 사이클1: 페어 프로그래밍

---

이번 장기 미션에서의 페어는 '밀란'이다. 

축구를 좋아해서 AC'밀란'의 밀란을 딴 이름인줄 알았는데, 그건 아니고 파스타를 좋아해서 이탈리아 도시인 밀란을 이름으로 했다고 한다.

참고로 축구는 관심 없다고 한다...

 

내 PR:

[🚀 사이클1 - 미션 (보드 초기화 + 기물 이동)] 제이 미션 제출합니다. by jhk01007 · Pull Request #197 ·

 

😃 Liked (좋았던 점)

• 페어 프로그래밍이 두번째라 그런가 걱정했던 것보다 매우 순조롭게 진행됐다. 이게 다 밀란 덕분이라고 생각한다.
• 설계 방식에 대해 토론하는 과정이 재미있게 느껴졌다.
  구현을 진행하던 중 설계가 다소 어색하다는 느낌이 들어 잠시 멈추고 화이트 보드에 적어가면서 설계에 대해 이야기를 나누었는데, 그 과정을 통해 더 나은 방향으로 구조를 개선할 수 있었다.

 

☹️ Lacked (부족했던 점)

• 내가 알고리즘 구현 능력이 많이 부족하다는 것을 체감했다.
  코딩테스트 공부를 안한지 오래돼서 그런지 기물의 이동 규칙을 구현하는 과정에서 많이 버벅였다.

 

🧐 Learned (배운 점)

• 객체지향 설계를 시작하는 새로운 방법에 대해 알게 되었다.
  밀란은 객체지향 설계를 시작하는 방식이 나와는 달랐다. 나는 요구사항을 먼저 쭉 정리하고 객체를 정리하는 편이라면, 밀란은 객체를 먼저 선별하고 그 객체를 기반으로 요구사항을 정리한다. 이렇게 하니 요구사항이 더 뚜렷해지는 느낌이 들었다.

 

🤗 Longed for (앞으로 바라는 점)

• 코딩테스트 공부를 다시 시작해야겠다는 생각이 들었다. 이전 블랙잭 미션부터 이번 장기 미션까지, 로직이 조금만 복잡해져도 시간이 오래 걸린다는 것을 체감했다.