우아한테크코스(프리코스) 4주차 회고

이번 주차 미션은 오징어게임에서도 나왔던 다리 건너기 게임이다.

https://github.com/woowacourse-precourse/java-bridge

GitHub - woowacourse-precourse/java-bridge

 

이번 주차를 진행하면서 우아한 테크 코스에서는 추가 요구사항을 부여했다.

추가된 요구 사항

이번 주차에서는 메서드의 길이가 15 -> 10 라인으로 축소되었다.

또한 메서드의 파라미터 개수 제한이 추가되었으며

 

사용하는 클래스들의 각각 스켈레톤 코드가 작성되어 주어졌다.

 

 

시퀀스 다이어그램

---

1. 기능 요구사항 작성

 

이번 주차에서는 저번 주보다 기능 목록을 작성하는데에 더 많은 시간이 투자되었던 것 같다.

저번 주차에서 기능사항을 꼼꼼하게 읽지 않아서 중간에 기능목록과 구현 내용을 수정해야할 부분이 있었는데 그런 부분을 최소화할 수 있도록 경우에 수에 대해서 계속 생각해보며 기능목록을 작성하였다.

 

---

2. MVC 패턴

이번 주차에는

• BridgeGame 클래스에서 InputView, OutputView 를 사용하지 않는다.

라는 명확한 사항을 제시하였다. 이번 주차에서는 많이 미숙할 수도 있지만, MVC 패턴을 도입하였다. 

웹 프로그래밍이 아닌, 콘솔 프로그램에서 어떻게 MVC 패턴을 적용해야 하나 많이 와닿지가 않았다. 

 

그래서 3주차의 다른 사람들의 코드도 많이 참고하고, 구글링을 하면서 어떻게 구성해야 할까에 고민을 끝마친 후, MVC 패턴을 적용하였다.

---

3. 예외처리

이번 주차에서 예외처리는 저번 주차와 요구사항이 달라졌다.

프로그램에서 예외가 발생하면

1. 예외를 던지고 -> 2. 예외 문구를 출력 -> 3. 해당 부분부터 다시 입력을 받는다.

 

다시 입력을 받는 내용이 추가되었다.

이 부분은 처음에는 확인하지 못했지만 요구사항을 재차 확인하는 과정에서 달라졌음을 확인하였다.

(그렇게 요구사항을 꼼꼼히 읽자고 다짐하였는데도 빠뜨린 내용이 있었다니... 사실 나 자신한테 조금 실망했다...)

 

결국 기존의 예외처리를 수정하게 되었다.

 

해당부분부터 다시 입력을 받으려면

1. 입력받는 부분에서 예외를 던진 후

2. 입력 받은 데이터를 사용하기 위해 무언가 처리를 하면서 예외를 받아 로그를 남기는 구조로 되어야 할 것 같다고 생각했다. 

 

이를 구현하기 위해서

입력부에서 예외를 던지는 것은 그대루 두었고

2번을 해결하기 위해서 입력받은 데이터를 사용하는 부분을 리팩토링 하였다.

 

입력받은 값을 사용하기 위해 반환하는 메서드 전체를 while 문으로 감싸고,

그 반복문의 내부를 try~catch 문으로 잡아

데이터를 입력받을 때, 예외가 발생하지 않았다면 return 으로 해당 메서드를 종료하는 방식으로 구현하였다.

예외가 발생하였다면 catch 문으로 예외를 받아 로그를 남기도록 구현하였다.

---

4. 출력 형식

이번 주차에서 가장 어려웠고 가장 시간이 많이 들었던 부분이 출력 형식을 맞추는 것이었다.

처음에는 대수롭지 않게 생각했지만

 

1. 위 블럭을 맞춰 움직인경우

2. 위 블럭을 선택했지만 틀린경우

3. 아래 블럭을 맞춰 움직인경우

4. 아래 블럭을 선택했지만 틀린경우

 

의 4가지 경우가 존재했고 이 4가지 경우를 어떻게 분리해야 할지 고민하면서 시간을 굉장히 많이 사용했다.

위 블럭 관련 출력 형식을 맞추고도 아래 블럭 움직임 관련 내용을 구현하다가 전부 지우고 처음부터 다시할 정도로 많이 어려웠던 내용이었던 것 같다. 

 

그래서 결국 구현한 방법은

1. 위 와 아래를 나눠서 구현한다.

2. 위 와 아래 각각의 출력형식을 맞추기 위해 마지막 전까지의 (맞아온 길에 대해서) 선택을 게임의 다리와 비교하여

다리의 옳은 블럭과 사용자의 선택이 같으면 O, 다르면 공백을 넣어 [ O ], [   ] 형태를 만들도록 구현하였고 각 내용에 | 를 추가하여 

[ O |] 혹은 [   |] 가 만들어 지도록 했다.

3. 마지막 선택에서는 틀린 경우 사용자의 선택이 위면 위의 출력 형식에 X , 사용자의 선택이 아래이면 아래의 출력형식에 X 를 추가하였고 성공인경우는 2번과 마찬가지로 구현하였다. 다만 두 경우 모두 마지막이기 때문에 [   |] 를 추가하지 않았다.

---

 

4주차 총평 :

저번 주차의 로또 미션을 끝마치고 나서 

처리하지 않은 예외사항, 지키지 못한 요구사항들이 너무나도 아쉬웠다고 생각되고 후회되어 이번 주차에서는 주어지는 요구사항을 철저하게 지켜보자고 생각했습니다.

 

이 와중에 가장 지키기 힘들었던 것은 메서드의 길이를 10라인 이하로 지키는 것이었습니다.

메서드의 파라미터 개수를 3이하로 유지하면서 메서드 라인을 10 이하로 유지하는 것은 매우 어려웠던 것 같습니다.

 

하지만 메서드의 길이를 줄이면 줄일수록 메서드에서 필요없는 부분은 없어졌고 

메서드 별로 책임이 줄기 시작했습니다. 

 

또한 메서드의 길이를 지키면서 메서드와 메서드간의 호출되는 관계에서 변수들이 어떻게 관계를 맺는 지에 대해서 많이 생각해보게 되었던 것 같습니다. 

원시타입의 경우엔 메서드에서 값이 반환된 것을 저장하여 사용해야 했습니다.

하지만 참조타입의 경우 파라미터로 들어온 값을 해당 메서드에서 변경시키면 그 값을 반환하지 않고도 해당 메서드를 호출한 상위 메서드에서 값이 변경되어 그대로 사용할 수 있어서 라인을 줄일 수 있었습니다.

 

또한 이번 주차에서 출력 형식을 맞추는 부분에서 상당히 고전했습니다..

 

그래도 코드를 다 짜고 나니 조금은 객체지향적인 코드를 작성했다고 생각되는 것 같아 조금은 뿌듯했던 것 같습니다.

 

이전에는 클래스의 분리 개념에 대해서 생각하면서 클래스의 책임, 메서드의 기능 들을 생각하면서 클래스를 분리한 것이 아니라,

코딩을 하면서 뭔가 필요한 데이터 뭉탱이가 있다면 그냥 단순하게 클래스를 선언해서 그 안에 때려박고 그 클래스에 마구잡이로 getter 와 setter 를 이용해 사용했었습니다.

하지만 이번 주차를 끝내고 나니 기존의 코드가 어떤 부분이 잘못되었는지에 대해서 생각해보게 되었습니다. 클래스의 책임과 또 각 클래스간의 연결관계 등을 생각하면서 클래스를 분리하고 무분별한 getter, setter 를 사용하는 것이 아니라, 클래스의 멤버의 불변성을 보장해주기도 하면서 좀 더 체계적이고 안정적인 코드를 작성할 수 있었던 것 같습니다.

 

마지막으로 프리코스 4기에 참여하면서 앞선 주차 소감에서도 이야기 했듯이 4주간에 정말 큰 성장을 이루었다는 생각을 했습니다.

물리적으로 보았을 때, 드라마틱하게 기발한 코드를 작성할 수 있는 그런 능력이 생긴 것은 아니지만

함께 일하는 개발자로서 성장하는 방향에 조금씩 맞추어 가며 방향적인 성장을 많이 이루었다는 생각이 들었습니다.

 

손 가는 그대로 코딩하는 것이 아니라,

코드를 작성하기 전에 어떻게 구현할지 전체적은 플로우를 그리며 기능목록을 작성하고

혼자만의 코드를 작성하는 것이 아니라,

누군가와 협업을 한다고 생각하며 가독성을 고려하면서 코딩하면서

 

비록 4주가 테스트를 위한 과정이었지만 

회사 어떤 집단에 한 명의 개발자로서 소속된 일원이 된 것 같은 느낌을 받아서 되게 좋은 경험이 되었던 것 같습니다.

 

프리코스가 끝나고 본코스에 합류할 수 있을지 없을지는 미지수지만, 

어떤 결과가 나오더라도 이번 프리코스를 통해 배우게된 개발자로서 성장해야할 방향에 대해서 끊임없이 생각하며 이를 발판으로 성장할 수 있는 제 자신이 되었으면 좋겠습니다. 좋은 기회 만들어주셔서 정말 감사했고 정말 좋은 경험이었습니다. 감사합니다.