[우테코] 프리코스 2주차 회고 - 자동차 경주 게임

3주차 안내 메일

 

이번 과제는 거의 12시 직전에 마음 졸이며 냈는데 무사히 제출 되었다😭

3주 차는 적어도 월요일 까지는 소감문 제출까지 끝내야지😂💦💦💦

 

1주차 때 어느 정도 감을 잡은건지 2주차는 비교적 수월하게 진행할 수 있었다.

 

---

📜 구현 기능

 

• 경주 할 자동차 이름 입력받기
  - 이름은 쉼표(,) 기준으로 구분
  - (e) 자동차 이름은 5자 초과하는 경우
  - (e) 자동차 이름이 중복으로 존재하는 경우
  - (e) 자동차 이름이 공백 ""인 경우
  
  
• 시도할 횟수 입력받기
  - (e) 숫자 외의 문자가 입력되는 경우
  
  
• 레이싱 시작 (각 자동차는 전진 또는 멈춤)
  - 시도 횟수마다 각 자동차의 전진 상태 출력
  
  
• 우승자 안내 출력
  - 우승자가 여러명일 경우 쉼표(,)로 구분
  
  
• 예외 발생할 경우 '[ERROR]'로 시작하는 에러 문구 출력

 

---

👍 새로 달성한 목표

 

[테스트 코드와 함께 개발하기]

 모든 로직을 작성한 후에 테스트 코드를 작성하는 것이 아닌 테스트를 진행하며 개발을 할 수 있도록 노력했다. 아직 테스트 코드 작성이 미흡한 편이라 그런지 개발 시간이 단축된다는 느낌은 못받았지만 매번 메인 메소드를 실행시키지 않은건 확실히 큰 장점인 것 같다. 지난 번에 우테코의 테스트 API를 분석하다 Mockito라는 것이 나와서 공부해봤는데 아직까지는 사용해볼 일이 없었어서 아쉽다.

 

[입출력 관련 메소드 분리하기]

 1주 차를 진행했을 때 Number 객체에 입력을 위한 메소드가 존재했다. 모든 로직을 작성하고 테스트 코드를 작성하려고 해보니 테스트 코드에서는 콘솔 입력을 어떻게 하는지 몰라 난감했던 기억이 난다. 결국 임의로 값을 세팅하는 테스트용 메소드를 생성하였었는데 애초부터 입출력 메소드와 Number 클래스가 분리되었었다면 테스트 코드 작성이 훨씬 더 수월했었을 것이다. 

 

 위 내용은 요번 주차 피드백에 연관된 내용이기도 하다. 🤗 나는 웹 개발을 해와봤어서 그런가... 컨트롤러와 엔티티를 분리한다는 개념으로 접근해서 위와 같은 발상을 하게 되었는데 UI 로직과 비즈니스 로직을 분리한다는 말이 정확한 것 같다.

2주 차 피드백 일부

 

[메소드는 한 가지 기능만]

 본래 알고 있던 사항이었지만 이번 주 차에는 '15줄 이하'라는 새로운 제한이 생겼다. 메소드를 작성하다 보면 15줄을 넘어가는 일이 가끔 있었다. 더 구체적으로 분리하며 단 하나의 기능만 할 수 있도록 더 신경 썼다. 놀랍게도 다소 모호하게 느껴지던 메소드 이름들이 단순 명확해진다는 것을 느꼈다.

 

[IntelliJ 사용해보기]

 기존에는 Eclipse를 사용했으나 현재 진행중인 토이 프로젝트에서 IntelliJ를 사용했으면 좋겠다는 의견이 나와... 우테코에서도 사용하기 위해 적응하는 시간을 가졌다. Eclipse와 대부분의 단축키가 달라 단축키를 찾아보는데만 꼬박 하루가 걸리기도 했다. (정리한 단축키는 TIL로 작성해두었다.)

GitHub - yeon-06/TIL_challenge: 2021.11.08 ~ 2021.12.31 TIL 챌린지

 

[Git 명령어 공부하기]

 IntelliJ를 사용하며 Git 브랜치를 잘못 생성한다던가 커밋한 내역을 되돌려야 하는 상황 등... 수많은 실수를 겪었다. 이 기회에 Git 명령어를 공부하면 툴에 상관 없이 Git을 다룰 수 있겠다는 생각에 간단하게 공부를 해보았다. (정리한 깃 명령어들은 TIL로 작성해두었다.)

GitHub - yeon-06/TIL_challenge: 2021.11.08 ~ 2021.12.31 TIL 챌린지

 

---

🤯 겪었던 문제

 

[특정 커밋만 반영하기] 

과제가 발표된 이후에 일부 코드를 변경해야한다는 메일이 도착했다.

메일 내용

이미 많은 코드를 수정중이었고... '나중에 수정해도 되겠지!' 라는 안일한 생각에서 나의 삽질이 시작되었다. 어느 정도 기능을 구현한 후에 아 맞다, 그 파일 수정해야했지? 라는 생각이 들었을 때 쯔음에는 내 커밋 목록이 많이 쌓여있었다. 레포지토리를 새로 fork 받는건 말도 안되고 바로 pull 받자니 기존 코드가 사라지지는 않을까 무서웠다. (이 때는 깃 명령어를 공부하기 전이라 fetch와 merge를 따로 진행할 수 있는것을 모르기도 했고 이미 두어번 파일을 날려서 똑같은 로직을 계속 새로 코딩하고 있었다...😢) 이 때 Git 명령어에 대해 공부하기 시작했고 git cherry-pick이라는 명령어에 대해 알게 되었다. 해당 명령어로 특정 커밋만 내 브랜치에 적용함으로써 문제를 해결할 수 있었다.

 

[try-catch와 assertThrow()]

 변경된 파일을 늦게 반영한 것에 대해 변명을 해보자면... 기존 테스트 코드로도 돌아가야 한다는 내 착각의 영향이 컸다. 😂 AS-IS와 TO-BE의 테스트 코드는 아래와 같다.

// AS-IS
@Test
void 이름에_대한_예외_처리() {
    assertSimpleTest(() ->
        assertThatThrownBy(() -> runException("pobi,javaji"))
            .isInstanceOf(IllegalArgumentException.class)
            .hasMessageContaining(ERROR_MESSAGE)
    );
}

// TO-BE
@Test
void 이름에_대한_예외_처리() {
    assertSimpleTest(
        () -> {
            runException("pobi,javaji");
            assertThat(output()).contains(ERROR_MESSAGE);
        }
    );
}

• AS-IS: IllegalArgumentException의 발생 여부
• TO-BE: 콘솔에 출력된 로그에 ERROR_MESSAGE가 포함되어있는지 여부

사용자가 입력을 잘못하면 Exception 처리를 해놓았고 입력을 계속 받아야하기 때문에 try-catch로 감싸두었다. 그러자 assertThatThrownBy()가 Exception을 인식하지 못하는 듯 했다. 인식하게 하기 위해서는 예외 전파를 하거나, 테스트 해야하는 메소드를 변경해야하는데(위와 같은 경우에는 메인 메소드를 실행시킴) 테스트 코드는 주어진 것이라 변경할 수 없었다. 이에 관해서는 따로 포스팅을 하였다. (https://yeonyeon.tistory.com/168)

[Java] org.opentest4j.AssertionFailedError: Expected ... to be thrown, but nothing was thrown. 에러

 

---

🐱‍👓 반성할 점

 

 기한 내 기능 구현에 급급해 당장 눈앞의 궁금점만 해결하는 것이 느껴졌다. 이전에는 호스팅 뜻이 뭘까? 라고 찾아보면 호스팅의 개념부터 종류와 그들 간의 차이점 등등 세부적으로 찾아보고는 했는데 2주 차 때는 오류 이런 뜻이고요, 이렇게 해결하면 됩니다. 식으로 마쳐 포스팅의 질이 좀 떨어졌던 것 같다. 개발자로서 오래 공부하기 위해서라도 자꾸 그렇구나~하고 넘기는 태도를 고쳐야겠다. '개발자의 공부는 깊게 진행되어야 한다.'를 다시 되새기는 주 였다.

 

---

✨ 피드백

 

지난 주차와 동일하게 전체 메일로 공통 피드백을 정리해서 보내주셨다.

 

• 기능 목록 구현 재검토
• 하드 코딩 금지
  
  
• 축약 금지
  
  
• 예외 케이스 고민해보기
  
  
• 주석은 꼭 필요한 경우에만
  
  
• Java의 API 적극 활용
  
  
• 배열 대신 Java Collection 활용
  -> List, Set, Map 등의 Java Collection 자료 구조를 사용하면 다양하고 편리한 API 사용 가능
  
  
• 데이터를 꺼내기보다는 객체에 메시지 전송
  -> 값을 비교하기 위해 get메소드 생성보다는 비교할 값을 파라미터로 보내 비교 결과를 알려주는 메소드 생성
• 필드 수 줄이기 위해 노력하기
  
  
• 비즈니스 로직과 UI 로직 분리