2023년 10월 24일 15시부터 6번째 우아한테크코스 프리코스가 시작됐다.
이 때가 딱 중간고사 기간이어서 무엇을 해야할지 고민을 했었는데 미션을 끝내는 것을 우선으로 생각하고 했다.
이런식으로 시작전에 메일이 한 번 오고 시작할 때
이렇게 메일이 한 번 더 왔다.
첫번째 미션은 숫자야구 미션이었다. 이번년도 5월쯤에 공부를 하면서 한 번 해본 경험이 있었다. 한번 해본 미션이라 크게 부담이 되지는 않았다. 그 동안의 나는 설계를 하지 않고 무작정 코드부터 작성했는데 그렇게 진행하면 코드의 구조가 이상해져서 설계를 제대로 해보기로 했다.
숫자 야구 게임을 시작합니다.
숫자를 입력해주세요 : 123
1볼 1스트라이크
숫자를 입력해주세요 : 145
1볼
숫자를 입력해주세요 : 671
2볼
숫자를 입력해주세요 : 216
1스트라이크
숫자를 입력해주세요 : 713
3스트라이크
3개의 숫자를 모두 맞히셨습니다! 게임 종료
게임을 새로 시작하려면 1, 종료하려면 2를 입력하세요.
1
숫자를 입력해주세요 : 123
1볼
...
미션의 흐름은 이랬다
흐름을 보고 로직을 짜봤다
코드를 짜면서 적용할점들을 생각해봤다.
처음으로 한 일은 클래스를 구분하는것이었다.
구현은 이렇게 진행했다.
처음은 설계를 바탕으로 기능 목록을 작성했다
이전에 코드를 짜 보면서 느낀점은 메세지들은 Enum으로 한번에 관리하는 것이 편하다는 것이다. 메세지를 사용하는 클래스 안에 넣어놓으면 코드가 복잡해지고, 알아보기 어려웠다.
1주차 미션을 진행하면서 가장 신경을 썼던 것은 전략패턴을 사용하는 것이었다. 컴퓨터가 숫자를 만들때 변경이 될 경우를 고려하여 숫자 생성전략을 주입하는 방식으로 코드를 짰다.
전략패턴을 선택한 이유는 단위테스트 때문이다. Randoms.pickNumberInRange()
를 사용해서 랜덤한 숫자를 생성하는데 이 기능을 테스트 할때 컴퓨터가 제대로 된 번호를 생성하는지 테스트를 하는 것은 의미가 없다고 생각했다.
저 메서드가 잘못 된 숫자를 생성했을 때 내가 해결할 수 있는 방법은 없다. 결국 숫자를 생성하는 메서드 자체를 테스트한다는 것은 컴퓨터와 싸우자는 소리가 아닐까 생각을 하다보니 전략 주입을 통해 테스트를 해야겠다고 정하게 되었다.
package baseball;
import java.util.List;
public interface ComputerNumberGenerator {
List<Integer> generateComputerNumber();
}
ComputerNumberGenerator
라는 인터페이스를 만들어
generateComputerNumber()
라는 메서드를 만들어서 구현을 강제화 해주었다.
그 후 implement
받아서 RandomNumberGEnerator
라는 클래스를 통해 랜덤 숫자 생성하는 함수를 만들어줬다.
package baseball.model;
import baseball.ComputerNumberGenerator;
import camp.nextstep.edu.missionutils.Randoms;
import java.util.ArrayList;
import java.util.List;
public class RandomNumberGenerator implements ComputerNumberGenerator {
public List<Integer> generateComputerNumber() {
List<Integer> computer = new ArrayList<>();
while (computer.size() < 3) {
int randomNumber = Randoms.pickNumberInRange(1, 9);
if (!computer.contains(randomNumber)) {
computer.add(randomNumber);
}
}
return computer;
}
}
이렇게 전략패턴을 이용하여 코드를 구성하면 나중에 컴퓨터가 번호를 생성하는 전략을 바꿀 때 새로운 전략을 만들어 주입만 해주면 돼서 유지보수에 좋다.
그 이후의 코드는 깃허브에 올라온대로다.
제출하고 인생처음으로 코드리뷰를 진행해봤다. 그냥 말하면 너무 딱딱하고 시비거는 것처럼 보여서 말투에 대한 고민을 많이하고 다른 사람들이 단 리뷰들을 보면서 생각해봤다.
보니까 이모지를 많이 쓰고 ~~한 방식이 좋아요
이런 말투 보다는 ~~한 방식이 좋다고 해요
나 ~~한 방식을 사용해보면 어떨가요 :)
이런 소프트한 말투를 사용하면 좋다고 느끼고 나도 리뷰를 달 때 그런식으로 달았다.
아직 이 말투가 익숙하지는 않은데 얼른 익숙해져야겠다!!
제출을 무사히 마쳐서 다행이다. 코드를 짜면서 공부하고 많이 배울 수 있었다. 그리고 설계 단계에서 좀 더 상세하게 짜는게 좋을 것 같다고 생각했다. 설계 단계에서 고려하지 못하 부분들이 나중에 문제가 되어 어려움을 겪었다.
혼자 공부할 때 숫자야구
https://github.com/grow-up-study/java-baseball/pull/1
깃허브 링크
https://github.com/woowacourse-precourse/java-baseball-6/pull/1874
멋있어요👍