2주차는 1주차와 비슷했다. 1주차를 이미 진행했어서 그런지 조금은 익숙해져서 더 쉽게 느껴지기까지 했다. 이번엔 큰 오류가 없었어서 그런거같다. 😁
요구사항
기능 요구사항은 1주차와 같이 어떤 프로그램을 만들어야 하는지 게임에 대한 설명이 있다.
프로그래밍 요구사항은 1주차에서 조건들이 추가되었다. 추가된 요구사항은 특별한 것이 없으나 이번엔 기본 클래스를 지정하였다. Car클래스 내의 멤버변수가 private이라 어떻게 값을 수정하고 가져올지 고민 많이 했다. 가져오는 것은 터미널에 값을 가져와 출력해야 하는데 Car클래스에서 출력 메소드를 선언하면 클래스 간 용도가 섞일듯해 getName()과 getPosition()은 선언하였다. position의 값을 수정할 때에는 해당 메소드를 호출하면 조건을 확인하고 +1해주었다.
기능을 구현하기 전에 java-racingcar-precourse/docs/README.md 파일에 구현할 기능 목록을 정리해 추가한다.
지난주에는 루트 경로에 있는 리드미였는데 이번주에는 docs폴더에 있는 리드미로 변경되었다. 막판에 급하게 수정하였다... 휴~^^;
이번 과제에 신경쓴 점
-
커밋 메시지
지난주 과제 메시지는 너무 설명충(ㅠ)이어서 조금 간략하게 해보았다. 간략하게 적더라도 리드미를 우선적으로 읽을 것이기 때문에 충분히 이해할 수 있을 것이다.. -
커밋 브런치
전주 목표에는 (까먹어서) 안적었는데 브런치를 제대로 나누어 보고 싶었다. 지난주 브런치 구조는yukong에서 개발을 하고,main은 가장 최신 코드를 유지했다. 결국yukong과main이 같았다.ㅋㅋ
이번주는 git 브런치를 나누는 기준을 찾아보고 적용해보았다. 배포 가능한 상태를 유지하는main, 개발을 진행하는develop, 각 기능을 개발하는feature/브런치명의 구조이다. 아직은 작은 프로그램이기 때문에 기능 브런치가 그렇게 많지 않았지만 프로젝트의 크기가 커질수록 feature 폴더 구조도 나눌 필요가 있어보인다. 또 기능 브런치는 명명규칙이 없기 때문에 그때그때 만들고있는데 조금 난잡해보인다. 기능 브런치 이름도 신경써서 만들어야겠다.
브런치 구조 참고사이트는 여기이다.
git client는 git fork를 썼다. 오징어 그림 있는거 쓰고 싶었는데 무료버전은 private 저장소를 지원하지 않아 fork를 선택하였다. -
클래스 구조
지난주에 잘못된 상속으로 고생했었는데 이번에는 그런 일은 없었고 게임 구조도 전주와 비슷해 큰 이슈는 없었다. 무난무난~~😁😁 -
테스트코드 활용
테스트코드를 더 추가해보고 싶어서 JUnit을 간단하게 알아보고 테스트를 추가해보았다. 추가하다보니 중복코드가 많아졌는데 어떻게 메소드를 나눠야할지 아직은 모르겠다. 다음 과제에는 테스트 클래스를 깔끔하게 정리해보려한다. -
메소드 정리
이것도 전주 목표에는 없던건데 메소드를 잘게 나누다보니 하나의 클래스 내에 메소드가 많아져 가독성이 떨어져보였다. 어떻게 해결해야할지 고민하고 있었는데 1주차 공통 피드백에서 영감을 얻었다. 개인 메일로 온 피드백이라 전체 내용을 공개할 수는 없으나 일부만 가져와보자면,공백 라인을 활용해보라는 것이었다. 각 메소드에서 메인 기능을 하는 메소드를 기준으로 메인 메소드에서 파생된 메소드들을 공백 라인으로 묶어 표시하였다.
RacingGame클래스를 예시로 보면, main 메소드에서 실행시키는 play에서 호출하는 4개의 메소드를 메인 메소드로 보았다. 각 4개의 메소드에서 파생된 여러 메소드들을 공백 라인을 기준으로 나누어 더 가독성이 높아졌다. 근데 이 방법도 프로젝트의 크기가 커질수록 어려울듯하다. 전주에 추가했던 Array클래스처럼 성격이 다른 메소드들은 클래스를 분리하는 등 다른 방법을 생각해봐야겠다. -
입력값 예외처리
이번 과제에서 입력값은 자동차 이름과 시도 횟수 총 두 개이다. 각 입력값에 대해 조건이 자세하기 주어지지 않아 어떤 상황에서 예외처리 할 것인지 고민 많이 했다.
먼저 자동차 이름에서 주어진 조건은자동차 이름은 쉼표(,)를 기준으로 구분하며 이름은 5자 이하만 가능하다.뿐이다. 우선 이름이기 때문에 빈값은 제외하였고 동일한 이름에 대한 처리는 하지 않았다.(아이디가 아니라 이름이니까) 입력한 값 앞 뒤에 있는 공백은 자른 후 자동차 이름을 저장하였다. 다음 시도 횟수는사용자는 몇 번의 이동을 할 것인지를 입력할 수 있어야 한다.밖에 없다. 사실 예외 처리 조건에 대한 것이 없는 것이나 마찬가지이다..(ㅠ) 일단 입력값이 숫자라는 것은 변하지 않으므로 이름과 마찬가지로 빈값제외를 하고 숫자 처리도 하였다. 시도 횟수는 음수가 될 수 없으므로 음수도 제외하였다.
조건에 대해 자세하게 주어지지 않아 어느정도까지 해야하는지, 우테코 측에서 생각하는 기준이 나와 맞는지를 가장 많이 고민했다. 일단 내가 생각했을 때 필요한 것들은 최대한 추가하였다. -
MVC 구조
다른 분들이 제출한 과제를 보면 꽤 많은 분들이 MVC 패턴을 따랐다. 처음엔 작은 프로젝트였기 때문에 그럴 필요성을 느끼지 못해 나는 MVC 패턴을 따라가지 않았는데 조금 후회된다..ㅎㅎ 3주간의 프리코스가 최종 코테를 준비하는 시간이라고 생각하는데 자바로는 MVC 패턴을 구현해보지 않아 갑자기 구조를 변경하려면 많은 시간이 소요될듯하다. 요구사항 중에서도 MVC 패턴에 대한 얘기는 없으므로 일단은 내가 해오던 방식으로 시험을 볼 생각이다.
2주차 과제를 마치고
1주차와 난이도가 비슷했고 별다른 오류가 없었어서 무난하게 끝마쳤다. 3주차부터 갑자기 요구사항이 많아지고 최종 코테와 비슷한 난이도로 올라간다는데 조금 걱정된다. 😅 그래도 전주에 목표했던 것들을 이번에 모두 적용해서 뿌듯하다. 😊😊😊
다음 과제에 신경써야 할 것들
-
기능 브런치 구조 및 이름
잘 정리된 코드들을 보다가 브런치명을 보면 이게 뭐지 싶다.ㅋㅋ 다음 과제에는 자체적으로 규칙을 설정하고 지키려한다. -
테스트클래스 정리
현재 코드는 중복 코드가 너무 많다. 더 간단하게 정리할 수 있을텐데 자바에 대해 모르는 것이 많아 못했다. 다음에는 간결하게 정리해보고싶다.
다음 목표는 프로젝트외의 것들밖에 없다. 아직까지는 공통 피드백에 있는 내용이 내가 지키려 했던 것들이 많아서 크게 신경써야 할것들이 없다. 2주차 공통 피드백과 3주차 과제를 보고 그 때 다시 생각해봐야겠다.
2주차 과제 리팩토링
20211217 추가
1주차 리팩토링한 것과 동일한 구조이다. 요구사항 중에서 Car의 private 변수를 setter 메소드를 사용하지 않고 구현한다, 가 있어서 repository는 제외하였다. 하지만 결국 우승자를 출력하는 과정에서 getter 메소드를 사용하기는 했다...ㅠ
이전에는 error 메시지도 Error 클래스 객체에 일반 멤버변수로 선언했었는데 각 에러메시지가 어떤 변수의 에러메시지인지 한눈에 알아보기 어려웠다. Error도 마찬가지로 Enum 클래스로 선언해서 어떤 입력사항에 대한 에러메시지였는지를 나타냈다. 처음 Enum 클래스를 접했을 때에는 그래서 언제 쓰는건지 알 수가 없어 어려웠는데 실제로 사용해보니 조금은 감이 오는 느낌이다. 😁😁
20211207 깃 브런치 규칙 추가
