[우테코] 우아한테크코스 5기 프리코스 4주차 다리건너기 회고

 

 

💋 인트로

 

이번 포스팅에서는, 우아한테크코스 5기 프리코스 4주차 다리건너기 회고에 대해 작성해보려고 합니다. 

 

 

💋 회고

4주차는 "객체를 객체답게" 사용하는 것에 가장 몰입했습니다. 

 

BridgeGame에 view와 관련된 코드를 넣지 말라는 요구사항을 읽고 우테코에서 MVC 패턴을 적용하기를 원하는 것 같다고 생각했습니다. 따라서 처음에는 기능을 구현하는 것과 MVC 패턴을 적용하는 것만 고려한 채로 코드를 작성했습니다. 3주차에 이미 접했기에, 스스로 MVC 패턴의 장점과 필요성에 대해서는 충분히 용납할 수 있었던 상황이었고, 잘 이해하고 있다고 생각했습니다. 처음에 구현한 코드는 하지만 그닥 직관적이지 못했습니다. 게임의 최종 성공여부와, 한 번의 이동에서 발생하는 생존 여부를 엮은 로직 등이 서로 얽혀 있었습니다. 왜인지 모호한 느낌이 들어 게임 플로우차트를 그려 보았고, 로직이 많이 얽혀있는 것을 발견해 리팩토링을 통해 크게 코드를 수정하기로 했습니다. 

리팩토링 전에, 구현하고 싶은 로직을 직관적인 플로우 차트로 표현해 차트에 따라 작성한 코드의 순서를 바꾸기 시작했습니다. 3주차의 로또 미션은 값을 입력받아 프로그램 내에서 계산한 결과값을 출력하면 되었기 때문에 MVC로 분리하는 것이 비교적 수월했습니다. 하지만 4주차의 경우, 사용자의 선택에 따라 로직의 중간으로 들어가 다시 플레이 하는 상황이 있었기에 수월하지 않았습니다. 원하는대로 코드를 완성했지만, BridgeGame에서 controller와 view의 코드를 사용하고 있었습니다. 

클래스의 역할에 대해서 고민하게 되었습니다. 한 클래스가 하나의 일을 한다고 하는데, 일이라는 것이 굉장히 모호했습니다. 하지만 계속해서 코드를 보다 보니, controller의 역할을 현재 BridgeGame에게 많이 넘겼기 때문이라는 생각이 들었습니다. '게임을 관리하는' 이라는 역할을 가진 BridgeGame은 시도 회수, 성공 여부, 다이어그램(map)을 관리하는 역할만으로 충분하다고 생각했고 그렇게 리팩토링하자, 처음의 문제점이 자연스레 해결되었습니다. 이전의 문제는 제가 하나의 클래스에게 한 가지 이상의 일을 시키고 있었기 때문에 발생했던 문제점이었습니다. 이 상태에서 플로우 차트를 코드를 보며 그리자, 직관적인 플로우 차트가 완성되었습니다. (README 파일에 첨부함)

"객체를 객체답게" 사용하는 것도 위의 노력과 연결되었습니다. 3주차 피드백을 읽고 다시 제 코드를 다시 보았을 때, 단순히 정보를 getter를 통해 외부로 내보내기만 하는 클래스가 있었습니다. 하나의 클래스에서 데이터를 생성한 뒤에 모두 외부에 보내주기만 하고, 클래스 내부의 역할은 아무것도 없었습니다. 객체를 객체답게 사용하는 것은 코드를 작성하는 것 외에도 많은 고민이 필요했습니다. 한 클래스가 어디서부터 어디까지의 일을 해야 하는지 그 경계가 모호했고, 때로는 게임의 로직이 이어지기 때문에 코드를 중간에 분리하는 것이 어려웠기 때문입니다. 객체에 메세지를 보내 일을 시킨다는 말이 처음에는 이해가 잘 되지 않았지만, 곧 제가 객체로부터 정보를 불러와 연산을 하고 있는 모든 순간을 분리해 객체에 넣으면 된다는 것을 알게 되었습니다. 결국 한 클래스를 하나의 주제라고 생각하고, 주제에 연관되지 않는 문장을 찾는 과정처럼 연관성이 없는 코드를 제거해 나가는 과정이 객체를 객체답게 사용하고, MVC 패턴을 적용하는 것과 일맥상통한다고 느꼈습니다. 

 

결국 하나의 클래스가 하나의 역할을 담당한다는 말의 의미를, 현재로는 프로그램의 관점에서 각 클래스의 역할을 짧은 한 문장으로 정리할 수 있다면 제대로 분리한 것이라고 생각하게 되었습니다. 따라서 README 문서에 MVC 패턴을 적용한 각 클래스의 역할을 한 문장으로 정리하고 각 메서드의 역할을 설명하는 문서를 작성했습니다. 

큰 리팩토링 중 얻게 된 것이 많았습니다. 이어지는 로직으로 인해 다른 클래스로 전달한 정보가 다른 클래스에서는 업데이트되지 않아 발생하는 문제도 많았습니다. 리팩토링의 중간 단계에서, Controller와 BridgeGame 클래스에서 모두 다이어그램을 필드로 가지고 있어서 Controller에서 만들어 BridgeGame으로 보내졌는데, 두 클래스에서의 다이어그램의 상태가 서로 동기화되지 않는 문제가 발생한 것입니다. 이 경험을 통해서 또 불필요한 필드가 왜 버그를 일으키는지 알게 되었고 필드를 최소화해야 하는 이유를 뼈저리게 느끼게 되었습니다. 또한 게임을 관리하는 BridgeGame 클래스가 필드를 독립적으로 관리해야 하는 이유에 대해서도 느끼게 되었습니다. 또한 클래스의 복제본인 인스턴스를 만들면서 static에 대해 꽤 깊이 공부하게 되었습니다. static 여부에 따라서 시도 회수나 항상 초기화해야 하는 다이어그램 등에서는 실제로 게임의 결과가 크게 달라졌습니다. 체크리스트에 Util과 같은 클래스가 아니면 static을 남발하지 말자고 써 놓으며 이제껏 static을 남발한다는 피어 피드백을 받았던 기억이 떠올라 부끄러웠습니다. 

또 지난 주 미션을 제출하고 얼마 지나지 않아, 제가 수익률의 세 자리 수 마다 쉼표를 찍는다는 요구사항을 놓친 것을 알게 되었습니다. JAVA 초심자였지만 누구보다 좋은 코드를 작성하고 싶다는 욕심이 앞서 제대로 하지 못하는 MVC, TDD에 집중하다가 중요한 요구사항을 놓친 것 같아 반성했습니다. 

 

우테코 프리코스를 진행하면서 저는 많이 발전했습니다. 회고록을 작성하고 싶어서 블로그를 만들었고, 프로그래밍을 혼자 공부하던 것에서 벗어나 유능한 참가자들과 서로의 코드를 리뷰하게 되었습니다. 일주일 간 치열하게 고민한 하나의 문제를 다른 사람들이 다른 방식으로 구현한 코드들을 보면서 시야가 넓어졌습니다. 특히나 정말 상상도 못한 부분을 섬세하게 피드백해주시는 분들 덕분에 많이 발전했습니다. Constants를 클래스로 분리했을 때 생성자를 호출할 수 없도록 private 생성자를 만든다거나, 메서드를 지을 때 사용자 관점과 프로그램의 관점을 혼용하지 않도록 노력하는 등 제가 이전과는 비교할 수 없을 정도로 꼼꼼해 졌습니다.

 

JAVA를 전혀 할 줄 모르던 제가 한 달 만에 이제는 스트림까지 기초 문법을 편안하게 구현하게 되었습니다. 제가 어느 부분이 어떻게 약한 지 알게 되었고, 이제 최종 코딩 테스트를 응시할 수 있을 지는 모르지만 프리코스 이후의 기간 동안 알고리즘과 CS 공부를 할 충분한 동기를 얻었습니다. 정말 좋은 경험이었습니다! 감사합니다 !!! 

---

💋 나의 코드 

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

[다리 건너기] 조은기 미션 제출합니다 by eunkeeee · Pull Request #196 · woowacourse-precourse/java-bridge

제출 PR 링크는 후에 슬랙에서 계속해서 두고두고 사람들이 리뷰를 남겨줬다

이렇게 PR 링크에 사람들이 리뷰를 남겨주는데 첫 구현의 경우 피드백 + 나의 대답 댓글이 거의 백 개가 다 되어갈 정도로 핫 해졌다.... ㅎㅎㅎㅎ 우테코 참여하고 제일 좋았던 부분이고 실제로 피어 리뷰 통해서 제일 빨리 배운 것 같다

아무튼 내 코드에 이렇게 많은 분들이 관심 가져주다니 너무 기분 좋았다

많은 사람들이 검토해준 만큼 최종 코테도 잘 준비했다

 

++

이건 또 효과가 있을 지는 모르겟지만, 돋보이고 싶어서 + 이렇게 하면 리뷰하는 사람들도

내가 그저 대강 만들어서 리뷰해달라고 올리는 사람이 아니다! 라고 생각해서 선뜻 먼저 귀한 시간 내서 읽어줄 생각이 들 것 같아서 이렇게 간단하지만 플로우차트도 만들어서 올렸다

 

 

💋 참고자료

 

https://mangkyu.tistory.com/47

[Java] static변수와 static 메소드

 

https://limkydev.tistory.com/197

[JAVA] 자바 인터페이스란?(Interface)_이 글 하나로 박살내자

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!