미션 내용
자판기를 구현합니다.
상품을 자판기에 입고하고, 돈을 투입하여 상품을 구매할 수 있습니다.
기능 목록
1. 자판기가 보유하고 있는 금액으로 동전을 무작위로 생성한다.
2. 입력값 유효성 검사: 실패시 Exception 발생 및 에러메시지
- 구분자 ';' 로 split 했을 때 각 문자열의 처음과 끝은 '['와 ']'여야한다.
- ','로 split 했을 때 세가지로 나누어져야한다.
① 상품
- 구분자 ';' 로 split했을 때 각 문자열의 처음과 끝은 '['와 ']'여야한다.
- []안에 상품 상세는 ,쉼표로 구분되어 이름,가격,개수가 입력되어야한다.
② 금액
- 양수인가?
- 상품 목록에 입력된 금액이 100원 이상인가?
- 상품 목록에 입력된 금액이 10원으로 나누어 떨어지는가?
③ 수량
- 양수인가?
3. 자판기에서 상품을 구매한다.
① pick up: 투입한 금액과 선택한 상품에 따라 상품목록의 잔여 개수 차감
② 유효성 검사
- 투입금액이 상품목록의 최저금액보다 적게 남았는가
- 상품목록에 선택한 상품이 없는 경우
- 선택한 상품의 잔여 개수가 남지 않은 경우
4. 잔액 출력
① 자판기의 상품 목록 중 상품의 최소금액보다 (투입)잔여 금액이 적은 경우
② 자판기의 상품(들)이 전부 소진된 경우
* 공통: Exception 발생 시 에러 메시지는 [ERROR]로 시작한다.
프로그래밍 요구사항
- JDK 버전 8
- 자바 코드 컨벤션을 지키면서 프로그래밍 한다.
- indent depth는 2까지
- 3항 연산자는 쓰지 않는다.
- 함수의 길이가 15라인을 넘어가지 않도록 구현한다.
- else 예약어 사용X
- 만들어놓은 Coin 클래스를 사용해야한다.
- 그 외에 안내가 없는 경우, 파일 수정과 패키지 이동을 자유롭게 할 수 있다.
2주차 피드백
이번주도 공통 피드백의 내용 중에 기억에 남았던/도움이 되었던 피드백에 대해 몇가지만 적어보려고 합니다.
1. 발생할 수 있는 예외 케이스에 대해 고민한다.
- 정상적인 경우를 구현하는 것보다 예외 상황을 모두 고려해 프로그래밍하는 것이 더 어렵다.
2. git을 통해 관리할 자원에 대해서도 고려한다.
- .class 파일은 java코드가 있으면 생성할 수 있다. 따라서 .class 파일은 굳이 git을 통해 관리하지 않아도 된다.
- intellij의 .idea 폴더, eclipse의 .metadata 폴더 또한 개발 도구가 자동으로 생성하는 폴더이기 때문에 굳이 git으로 관리하지 않아도 된다.
3. java 에서 제공하는 api를 적극 활용하고, 배열 대신 java collection을 사용하라
- 기능이나 자료구조가 없는 경우만 직접 구현한다.
4. 객체에 메시지를 보내라
- 상태 데이터를 가지는 객체에서 데이터를 꺼내려(get) 하지말고 객체에 메시지를 보내라
- 예를 들어 Car가 우승자인지를 판단하기 위해 최대 이동거리 값을 가지는 Car인지 판단하는 기능은?
private boolean isMaxPosition(Car car){ return car.getPosition() == maxDistance; }
위와 같이 구현하지 않고 다음과 같이 Car에게 메시지를 보내 구현한다.
car.isMaxPosition(maxDistance);
5. 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다.
- 필드(인스턴스 변수)의 수가 많은 것은 객체의 복잡도를 높이고, 버그 발생 가능성을 높일 수 있다.
- 중복이 있거나, 불필요한 필드가 없는지 확인해 필드의 수를 최소화 한다.
6. 비즈니스 로직과 UI 로직을 분리해라
- 비즈니스 로직과 UI로직을 한 클래스가 담당하지 않도록 한다. 단일 책임의 원칙에도 위배된다.
- 현재 객체의 상태를 보기 위한 로그 메시지 성격이 강하다면 toString()을 통해 구현한다.
- View에서 사용할 데이터라면 getter메서드를 통해 데이터 전달
3주차 회고
2주차 보다 고려해야될게 훨씬 많았던 미션이었습니다.
input 형식이 달라져서 입력값을 처리해야 하는 부분도 생겼고, 지난 주 보다 고려해야할 예외상황도 많았습니다.
따라서 관련 함수와 클래스 추가로 구조도 좀 더 복잡해졌습니다. 그래서 구조 설계부터 "비즈니스 로직과 UI로직을 분리하라"고 했던 피드백을 다시 떠올리며 시작했습니다.
구현 중에는 필드 수를 줄이라고 했던 피드백을 신경쓰면서 구현하려고 했고, 중복되는 부분도 제거해보려고 노력 하였습니다.
지난주에 나름 구조에 대한 틀을 잡았다고 생각했지만, 조금 더 복잡해졌다고 다시 다른 고민들이 많이 생기더라고요.
* 구조
- validation코드를 어디에 넣어야하는지, 폴더를 따로 구분해서 두는게 좋을지 아니면 객체를 역할에 따라 좀더 세분화 해서 그 안에 넣어야 하는지
- Controller랑 Service랑 다른 역할인 것 같은데 Service만 모아놓는 폴더를 따로 만들어야 하는지 아니면 Controller랑 같이 둬도 되는지
- DTO? VO? 다른 분들 코드에서 나눈 분들도 있고, 안 나눈 분들도 있는데 이번엔 나누지 않았지만, 코드가 더 복잡해질 경우 객체 관리를 위해 나누는 게 좋을 것 같다는 생각.
* Stream
- stream을 사용하면서 코드를 더 간결하게 사용할 수 있었음. 하지만 아직 학습이 부족해서 응용이 어려움. stream에 대해 더 공부해볼 것(filter, map, sort 등등)
* 테스트
- 코드를 구현할 때 객체를 먼저 어느정도 만들고, 필요한 상수를 담아놓는 클래스를 어느정도 만들어 놓고, 서비스 관련 로직을 구현한다. 그런데 프로그램은 결국 main에서 controller를 만들어 실행시키게 되는데, 중간에 테스트가 필요한 경우 어떤식으로 해야할지 고민... (단위 테스트 하는 방법)
* enum
- 사용해본 적이 없어서 조금 헤맸었던 부분
- (최종 코테를 보고나니 더욱이 드는 생각,,) 어떤 상황에 쓰는지 어떻게 활용할 수 있는지 더 공부해봐야할 것 같습니다.
3주동안 프리코스를 진행해보면서 내가 잘하고 있다고 생각했던 부분은 다시 돌아볼 수 있었고, 협업에서 지켜야할 부분들에 대해서는 새로 배울 수 있었습니다. 개인적으로는 저의 나쁜 습관을 고치고(주석, 변수 이름 짓는 부분 etc) 좀 더 효율적인 코드를 짤 수 있도록 개선한 것에 대해 정말 의미를 두고 싶네요. 1:1 피드백은 없었지만, 공통 피드백도 정말 도움이 많이 되었던 것 같습니다. 최종 코딩 테스트는 많이 아쉬움이 남았지만, 재밌었던 프리코스 였습니다.
- 관련 포스팅 -
[우테코] 2주차 미션 회고록: 자동차 경주 게임
[우테코] 2주차 미션 회고록: 자동차 경주 게임
2주차 미션 내용 자동차들끼리 경주하여 최종 우승자를 출력하는 게임을 구현합니다. 1. 입력 [자동차] - 자동자이름을 쉼표로 구분하여 입력받습니다. - 자동차 이름은 5자 이하여야 합니다. [
arinnh.tistory.com
* 메인 블로그로 운영중인 네이버 블로그에 올렸던 포스팅을 뒤늦게 가져오게 되었습니다.
'Programming' 카테고리의 다른 글
| [우테코] 2주차 미션 회고록: 자동차 경주 게임 (0) | 2022.01.03 |
|---|---|
| [우테코] 1주차 미션 회고록: 숫자 야구 게 (0) | 2022.01.03 |
| [우아한 테크코스] 지원 후기(+1차 결과) (0) | 2021.12.05 |
