[우아한테크코스 웹 백엔드 6기] 미션 - 숫자 야구 회고

문제 설명

---

미션 - 숫자 야구

 

미션은 이전 기수에서도 나왔던 숫자 야구 문제였다.

이전 기수에서는 2주차 미션으로 나왔지만 이번에는 1주차 미션으로 출제되었다.

 

미션을 읽어보며 가장 먼저 눈에 띈 부분은 '기능 목록' 작성이었다.

'기능 목록'은 개발 프로젝트를 계획하고 관리하는 데 있어 중요하다.(목표 설정, 작업 분할 및 할당, 개발 진행 상황 추적 등)

그래서 미션 시작 전 기능 목록을 먼저 생각하고 작성해보는 시간을 가졌다.

 

기능 요구 사항

 

기능 요구 사항을 살펴본 결과, 일반적인 숫자 야구 게임과 크게 다르지 않았다.

 

주로 고민한 부분은 컴퓨터가 생성한 난수와 사용자가 입력한 수를 비교하는 시간 복잡도를 어떻게 줄일 수 있을까였다.

그 외에도 사용자가 잘못된 값을 입력할 경우의 예외 처리 방법도 함께 고민하여 '기능 목록' 문서에 추가하였다.

 

프로그래밍 요구 사항

 

프로그래밍 요구 사항 중 특별히 주목할 만한 부분은 'JDK 17 버전의 사용'과 'Java 코드 컨벤션 가이드 준수'였다.

 

평소 JDK 11 버전만 사용해왔기 때문에, JDK 17 버전 설치와 그 버전의 특징들을 파악하는 것이 필요하다고 판단되었다.

따라서 JDK 11과 JDK 17 사이의 주요 변경사항들, 예를 들어 Records (JEP 395), Pattern Matching for instanceof (JEP 394), Sealed Classes (JEP 397) 등을 살펴보았고, 이러한 과정을 통해 JDK 17의 새로운 기능들에 대해 알게 되었고, 이를 프로젝트에 적용하는 방법을 고민하였다.

 

또한 Java 코드 컨벤션 규칙 역시 중요한 요구사항이었다.

 

코드 컨벤션은 팀원 간의 협업을 원활하게 하고 코드의 가독성을 높이는 데 큰 도움이 된다.

 

코드 컨벤션 규칙을 적용하기 위해 다음 글을 참고하였다.

https://velog.io/@pgmjun/IntelliJ-%EC%BD%94%EB%93%9C-%EC%BB%A8%EB%B2%A4%EC%85%98%EC%9D%84-%EC%84%A4%EC%A0%95%ED%95%B4%EB%B3%B4%EC%9E%90-feat.%EC%9A%B0%ED%85%8C%EC%BD%94

[IntelliJ] 코드 스타일을 설정해보자 (feat.우테코)

 

과제 진행 요구 사항

 

 

---

 

느낀 점

---

문제를 보자마자 1주차인 만큼 배려해준 것이 느껴졌다.

 

개발 시작 전 '기능 목록'을 먼저 작성하였다.

큰 틀부터 하나하나 작성하고 각각에 대한 세부사항을 작성하는 식으로 하였다.

 

요구사항이 그리 까다롭지 않아서, 별도로 프로젝트 구조를 설계하지 않고 바로 main() 메서드에서 문제 해결에 들어갔다.

그런데, 우아한테크코스 6기 디스코드 방에서 다른 사람들이 각자의 '학습 목표'를 가지고 프로젝트에 임하는 것을 보았다. 그들의 학습 목표 중 'OOP 적용', 'jdk17 활용', '클린 코드', 'TDD' 등이 있었다. 이것들을 보며 나 역시 나만의 학습 목표를 설정하게 되었다:

1. 모든 기능이 정상적으로 동작하도록 한다. (중요!!)
2. 디스코드 '우아한테크코스 프리코스' 방에서 공유된 정보를 내 코드에 적용해보며 이해한다.
3. SOLD 원칙을 최대한 적용해보자.
4. 역할과 책임을 분리한다.
5. 단위 테스트 코드를 작성해 코드의 신뢰성을 높인다.
6. 프리코스 미션의 의도를 파악한다.

 

따라서 첫 번째 단계로 역할과 책임 분리를 위한 패키지 구조 설계부터 시작하였다.

역할과 책임 분리는 다양한 방법으로 가능하지만, 나는 평소 사용하던 controller, service, domain 패턴으로 구분하여 진행하였다(앞으로 mvc 패턴도 시도해볼 계획). main() 메서드에서 바로 코드를 작성하는 것이 쉬웠지만, 패키지 구조를 나누어 책임을 분리하는 것은 생각보다 어려웠다. 그러나 이 과정을 통해 SOLID 원칙을 실천하고 코드의 유지보수성을 높일 수 있었다.

 

그 다음으로 단위 테스트 코드를 작성하려고 시도했다. 하지만 몇 가지 문제가 있었다.

1. Console, Randoms 클래스를 사용하여 테스트하기 어렵다.
2. 단위 테스트를 적용해야 하는 메서드의 접근자가 private이다.

특히 두 번째 문제는 평소에도 개발하면서 고민하던 부분이었다.

private 접근자를 사용하는 이유는 객체 지향 프로그래밍의 캡슐화 원칙을 준수하기 위함이다. 단위 테스트 하나 때문에 private 접근자를 public으로 변경해 캡슐화 원칙을 위배하는 것은 바람직하지 않다. 그래서 보통 해당 private 메서드를 호출하는 public 메서드의 테스트로 간접적으로 수행한다. 하지만 이번 미션에서 내가 구현한 public 메서드는 구조상 테스트 코드 작성이 어렵게 되어있다. 문제 해결 방안 찾기 위해 검색해봤으나 만족스러운 해결책은 찾지 못해서 결국 단위 테스트 코드 작성은 하지 못했다.

과제 진행 중 Markdown 문법에 대해서도 배울 기회가 있었다. README 파일 작성 경험은 있었으나, 규칙에 따라 Markdown 문법으로 작성한 경험이 없었다. 이번 기회로 Markdown 문법에 익숙해질 수 있어 유익한 시간이 되었다.

 

---

 

보완해야할 점

---

• 커밋 컨벤션 준수: 프로젝트를 진행하면서 커밋 메시지에 일관성이 부족했다. 앞으로는 커밋 메시지 작성 시 특정 규칙을 정하고 그에 따라 일관된 메시지를 작성하는 습관을 들여야겠다.
• 단위 테스트 코드 작성: 단위 테스트 코드는 소프트웨어 개발에서 매우 중요한 부분이다. 이번 프로젝트에서는 단위 테스트 코드 작성에 어려움을 겪었으나, 다음 프로젝트에서는 더욱 신경 써서 구현할 계획이다.
• 클린 코드 작성: 클린 코드는 가독성과 유지보수성을 높여주므로, 항상 지향해야 하는 목표다. 변수명, 함수명 등 모든 네이밍은 명확하게 하며, 함수의 길이도 가능한 짧게 유지하여 한 가지 기능만 수행하도록 해야한다.
• OOP 규칙에 맞게 작성: 객체 지향 프로그래밍(OOP)의 원칙들인 SOLID 원칙 등을 잘 이해하고 이를 바탕으로 코드를 설계 및 구현하는 것은 중요하다. 이번 프로젝트에서 OOP 규칙을 완전히 준수하지 못한 부분들은 다음 번에 개선할 필요가 있다.
• JDK17에 맞는 코드 작성: JDK17의 새로운 기능들과 변경 사항들을 잘 파악하여 최신 Java 버전에 맞춘 효율적인 코드를 작성하는 것도 중요한 과제다.
• MVC 패턴 적용하기: MVC 패턴은 역할과 책임 분리에 크게 도움되므로 다음 번 개발에서 적용해보려 한다.