우테코 프리코스 2회차 회고록

 

이전 글들

우테코 7기 프리코스 1주차 회고

우테코 프리코스 3회차 회고록

 

우테코 프리코스 4회차 회고록

 

우테코 프리코스 최종 코딩 테스트 회고

 

들어가며..

GitHub - changuii/java-racingcar-7: 우테코 프리코스 2주차

 

1주차는 문제가 조금 모호한 부분이 있다고 생각했다.

예를들면 //a\n{식} 이런 형태였는데, 나는 구분자가 여러개라고 판단했기 때문에 여러가지 경우의 수를 생각할 수 있었고 백슬래시가 정규식에 들어갈 경우 문제의 소지가 있었기 때문에 어려웠다

하지만 2주차는 racing car 문제였고 게임이라고 생각하니 오히려 요구사항을 구체화하고 생각하기 수월했기 때문에 조금 더 쉽다고 느껴졌다.

2주차 레이싱 카

이번 미션에서는 1주차에 막연하게 자세하지 않게 작성했던 기능 명세가 너무 간결하다고 느꼈기 때문에 이번 주차에서는 요구사항을 상세히 읽어보고 매우 자세하게 기능 요구사항 명세를 작성하려고 노력했다.

하지만 이때문에 “기능 명세”라는 것이 아닌 “클래스와 메서드의 명세”로 잘못 이해하고 설계하게 되었다.

• 하지만 생각만으로 명세한 클래스와 메서드의 설계들은 모호한 부분과 미처 생각하지 못했던 부분이 많이 존재했다.
• 그리고 이에 대한 고민을 쭉 해보았고, “기능 명세”라는 애플리케이션의 명세는 개발자만 보는 것이 아닌 개발자와 여러 이해 관계자들이 서로를 이해하는데 도움을 준다는 것을 알게되었고, 개발 명세라기 보다는 자연어로된 설명의 느낌으로 작성해야겠다고 깨달았다.

때문에, 이 후로는 “명세”에 집중하기 보다는 “기능”이라는 것에 집중하여 작성하였다.

바뀌기 전의 명세

**GameModel : 게임을 출력하거나 진행하는데 필요한 데이터를 담고 있는 클래스**

- 멤버 변수
    - String runnerNames : 자동차 이름들
    - int gameRound : 게임 라운드 수
    - List<Racingable> racingRunners : 참여하는 러너들
    - GameHistory history : 게임의 기록
    - List<Racingable> winners : 우승자들
- 메서드
    - setrunnerNames, getrunnerNames
    - setGameRound, getGameRound
    - setRacingRunners, getRacingRunners
    - addGameHistory, getGameResult
    - selectWinners, getWinners

• 개발을 하기 전에 이정도로 자세하게 작성해놓고 시작했다.

바뀐 후 명세

### 3. 자동차 이름과 이동 횟수를 검증한다.

> 검증 조건이 추가되거나 변경될 가능성이 있다.
> 
- [x]  입력으로 들어온 자동차 이름과 라운드 수를 검증한다. `(확장가능)`
    - [x]  자동차들의 이름이 1자 미만이라면 `IllegalArgumentException` 을 발생시킨다. `(판단)`
    - [x]  자동차들의 이름이 5자 초과라면 `IllegalArgumentException`을 발생시킨다.
    - [x]  자동차의 이동 횟수가 1 미만이라면 `IllegalArgumentException` 을 발생시킨다. `(판단)`
    - [x]  분리된 자동차들이 없다면 `IllegalArgumentException` 을 발생시킨다. `(판단)`

• 이렇게 누구나 이해할 수 있을 정도로 명세를 작성했다.
• 추가적으로 나는 객체지향이 미래에 대비하는 것이라 생각했기 때문에 복잡해지더라도, 추후에 혹은 미래에 변경되거나 확장될 가능성이 존재하는 부분에 대해서 명세를 작성해두고 이를 클래스나 인터페이스와 같은 부분으로 추출해서 구현했다.

하지만, 주차가 지날수록 요구사항이 복잡해지니 이런 부분까지 신경쓰다가는 개발을 완료하지 못할 것 같아 포기한 부분도 많이 있다 ㅎㅎ;

공통 피드백

이번 주차부터는 1주차에 대한 공통 피드백을 받을 수 있었다.

공통 피드백이지만, 나에게도 해당되는 말들이 많았고 고민했지만 어떤 것이 좋은지 답을 내리지 못했던 부분에 대해서도 명확하게 답변해주셔서 좋았다.

• 때문에, 해당 주차의 미션을 시작하기 전에 공통 피드백을 먼저 읽고 분석한 후 시작하는 것이 좋을 것 같다.

알게된점

이번 주차를 통해 알게된 점이나 학습한 부분은 다음과 같다.

1. 좋은 git 커밋 메시지 작성법
2. intellij에서 터미널 출력이 아닌 디버거를 사용하는 방법
3. .gitignore를 신경써서 사용하자!
4. 요구사항 기능 정의는 개발자간의 소통이 아닌 이해관계자와의 소통 그리고 자세한 설계로 인한 돌이킬 수 없는 개발,,..
5. View는 어떻게 테스트해야할까? → System.in, System.out 그리고 InputStream, OutputStream에 대하여 학습했다.
6. Stream.collect(Collectors.list())와 .toList()의 차이점
7. Integer.parseInt()와 Integer.valueOf()의 차이점
8. Stream을 사용하면 좋은 이유, 장점