우아한형제들과 NEXTSTEP에서 진행하는 우아한테크캠프를 지원하게 되었다.
변화하고 싶은 생각. 더 나은 개발자 고민.
지원자들이 괜찮은 기업을 다니다가 지원하는 케이스도 있다고 들었다. 그에 비하면 나는 그런 경험이 부족하다. 하지만 주어진 환경에서 회사의 사람들과 변화를 하려고 했던 경험. 더 나은 개발을 하기위한 노력들을 담아 지원서를 썼다.
메일이 왔다. 지원서와 프리코스의 미션수행에 따라 코스를 시작할 수 있다.
미션은 야구게임이었다. 야구를 3 스트라이크, 홈런밖에 몰라서 요구사항을 분석했다.
https://github.com/next-step/java-baseball-precourse
회사 입사지원 과제를 하다보면 압박감을 느끼는데, 생각보다 미션수행 시간이 넉넉했다.
프리코스에서 나는 무엇을 배울 수 있을까. 미션에서 하고 싶은 것을 포함해서 진행했다.
첫번째는 TDD이고, 두번째는 커밋주도개발이다. 미션을 진행하기전에 온라인에서 페어프로그래밍으로 TDD 개발을 하는 것을 본적이 있다. 요구사항을 정의하고 테스트=>프로덕션=>리팩터링 의 과정을 반복했다. 괜찮은 방법이라 생각해서 적용을 해봤다.
손에 익지는 않았지만 TDD 사이클을 스스로 실행해 나갈 수 있었다. 커밋 주도 개발은 미리 커밋메시지를 정의하고 그것에 따라 개발을 하는 것인데, 어느 부분까지 개발할 것인지 한계를 정할 수 있었다.
https://github.com/etff/java-baseball-precourse/tree/etff
요구사항은 구현하고 제출했다. 다음은 프리코스를 돌아보면서 스스로 피드백이다.
private void playGame(Ball ball, Score score) {
while (!(score instanceof Win)) {
BallNumbers playerInput = new BallNumbers(InputView.askBatInput());
Bat bat = new Bat(playerInput);
ScoreCalculator scoreCalculator = new ScoreCalculator();
scoreCalculator.calculateScore(bat, ball);
score = scoreCalculator.getScore();
OutputView.printScore(score);
}
} ScoreCalculator에서 calculate 를 수행한 getScore를 하는 데
굳이 왜 나눠서 진행할 필요가 있을까? scoreCalculator가 굳이 내부적으로 변하는 상태를 지니고 있어야 할까.
코드의 while (!(score instanceof Win))에서 종료조건이 아쉽다. 인터페이스는 세부 구현을 클라이언트 측에 숨겨서, 세부구현클래스에서 발생하는 변경사항이 클라이언트 측에 영향을 미치는것을 방지하기 위함인데 어떤 조건인지 코드에 드러나있다. score.isEnd() 를 같은 방향으로 개발하면 더 좋지 않았을까?
.png)
BaseBallNumbers라는 1급 컬렉션을 만들고 있는데, Validation이 분산되어있다. 유효성의 검사의 책임을 다하는 객체가 어디인지 고민이 필요할 것 같다.
마지막으로 사소한 부분이긴하지만, 사용자의 입력을 받는 부분의 예외처리가 안되어있다. 예를 들어 숫자입력 부분인데 문자를 입력하면 예외처리가 되고 애플리케이션이 종료된다. 예외처리만 할 것이 아니라 사용자에게 올바른 입력을 다시 받게하는 식으로 개발했으면 좋을 것 같다.
public askBatInput(){
try{
return BallNumber.convertBallNumber(scanner.next());
} catch (Exception e){
print(e.message);
return askBatInput();
}
}야구게임을 제출하고 첫번째 프리코스 미션을 마무리했다.
조금이나마 프리코스 미션을 통해 스스로 성장했으면 하는 바람이다.
