반응형

썸네일용 테스트 성공 화면. 수고했다 나 자신..

프리코스 4주간의 대장정은 끝이 났고,

전 세계는 프리코스 참가자들을 축하하며 '월드컵'이라는 축제를 열었다(?)

 

늘 다음 미션에 대한 기대감 반, 두려움 반이 공존된 상태로 회고를 적곤 했었는데,

기대와 두려움이 모두 사라진 평온~한 상태로 회고를 적자니 조금 어색하기도 하다.

 

쉼 없이 달려왔기에, 스스로에게 잠깐의 휴식을 주고 싶은데..

미뤄둔 할 일이 많아 쉽지 않다.

 

그런 와중에도, 4주 차 미션을 통해 배운 많은 것들에 대한 기억이 휘발되기 전에

회고를 적으려고 블로그를 켰다.

 

회고 시작시작!

 

 

목차

- 객체를 분리하다 MVC를 깨닫다

- 리팩터링이란 몰까..?

- 자연스러운 TDD

- 예외처리와 자만

- 프리코스 커뮤니티

 

 


객체를 분리하다 MVC를 깨닫다

3주 차에서 MVC 패턴이라는 나에게 어려운 개념을 지워버리고, 객체 간 관계에만 집중했었다.

그러다 보니 나도 모르게 Lotto 클래스와 같은 도메인 로직에서 입출력 클래스를 호출하곤 했다.

스스로의 코드를 읽어보며, 도메인 로직과 UI 로직이 완전히 분리된 것이 아니라는 생각을 했다.

 

이번 4주 차 미션에서는

"BridgeGame 클래스에서 InputView와 OutputView를 사용하지 않는다"

라는 요구사항이 적혀 있었다.

 

도메인과 UI 로직이 서로를 의존하지 않게 하기 위함이라고 생각했다.

그런데.. 도메인의 내용을 출력하거나, 입력을 받아 도메인 로직에서 사용하려면 결국 연결이 되어야 한다.

근데 도메인과 UI는 분리되어야 한다..

..

..

..

그래서 Controller가 생긴 것이구나!

라는 깨달음을 얻었다.

 

사실 대단한 깨달음도 아니고, MVC 패턴 관련 아티클을 정독하다 보면 자연스럽게 알 수 있는 내용이었지만,

아무리 아티클을 읽어도 나에겐 와닿지 않던 내용들이었다.

 

하지만 객체 간 관계, 도메인 로직과 UI 로직이라는 개념, 객체 간 의존 관계 등 객체에 대한 여러 개념을 이해하고 나니,

MVC 패턴이 왜 생겨났고, 어떻게 사용되어야 하는지 이해되었다.

그동안 나는 거꾸로 된 순서로 공부를 하고 있었다..!

 

정말 신기하고 뿌듯한 경험이었다. ⭐️

 

 

 

 

리팩터링이란 몰까..?

이전의 나에게 리팩터링이란 그저 '실수를 수정하는 행위'에 지나지 않았다.

 

하지만 이번 미션의 학습 목표 설명에

"먼저 기능이 작동하도록 구현하고, 리팩터링으로 코드를 개선해 보는 경험"

을 언급하셨다.

 

그 이유가 있을 게 분명했다.

그래서 나는 리팩터링이 왜 중요한지 그 의미를 생각하며 미션을 해결하려고 노력했다.

 

우선 내가 리팩터링을 좁은 의미로 생각한 이유를 고민했는데,

아마 코드를 수정하는 것이 두려워서였던 것 같다.

 

설계 없이 코드부터 냅다 작성하던 과거의 나에게, 코드 수정은 엄청 복잡한 일이었으리라..

하지만 지난 미션들을 해결하며, 유지보수가 훨씬 수월해졌음을 느꼈다.

용기를 갖고 많은 부분을 리팩터링 단계로 넘기리라 다짐했다.

 

그랬더니 생긴 이점들은,

기능 구현 시 흐름이 끊기지 않을 수 있었으며, 고민이 필요한 부분은 리팩터링 단계에서 충분히 고민할 수 있었다는 것이다.

이전에는 기능을 구현하면서 동시에 깊게 고민하고, 찾아보고, 공부하고.. 그러다 보면 프로그램 전체 flow가 헷갈리고..

이런 일이 많았지만,

리팩터링에 많은 부분을 넘기면서 훨씬 수월하게 기능 구현을 마칠 수 있었다.

 

몇 가지 리팩터링 한 부분이 기억에 남는데,

공통 피드백과 피어 리뷰 내용을 적용한 것이다.

공통 피드백의 객체를 객체스럽게 사용하는 방법, final 키워드 사용 방법,

그리고 피어 리뷰에서 배운 String 객체를 리터럴 방식으로 선언할 때의 이점 등을 공부한 후에 코드에 녹일 수 있었다.

 

그리고 30줄짜리 메서드를 10줄로 분리했던 경험도 생생하게 떠오르고, (분기되는 부분, 공통되는 부분을 기준으로 메서드 분리..!)

다리 현황을 기록하는 객체를 Monitor라고 칭했는데, Drawer(다리 그림을 기록하는 객체)와 picture(그림으로 된 다리 이동 기록)로 표현을 수정한 것도 기억에 남는다.

 

 

 

 

자연스러운 TDD

TDD가 자연스러웠다니.. 도저히 믿어지지 않는 일이다.

2주 차 요구사항으로 테스트 작성이 추가되면서, 넌지시 알고 있던 TDD 방식을 적용해보았다.

 

테스트 코드가 기능 구현 시 나침반, 설계도와 같은 역할을 해준다는 사실을 깨달았긴 하지만..

테스트 구현이 익숙하지 않은 채로 TDD 방식을 사용하는 것은 너무 고통스러웠다.

 

그런데 4주 차 기능을 구현할 때는,

아주 자연스럽게.. 테스트 코드에 먼저 손이 갔다.

 

객체와 책임을 먼저 설계했고, 테스트 케이스 구현이 익숙했기 때문에 가능했던 일이라고 생각한다.

추후에 스프링과 같은 프레임워크를 공부하더라도, 처음부터 TDD를 고집하면 굉장히 괴로울 것이다.

하지만, 기본적인 구조와 기능을 익히고 자연스럽게 TDD를 사용할 수 있다면 굉장한 무기가 되어줄 것이라고 생각했다.

 

기본을 공부하며 응용을 깨달은 이 경험이, 앞으로 나의 공부에 좋은 영향을 줄 것이라고 많이 기대된다.

 

 

 

 

예외 처리와 자만

지난 3주 차 미션의 최대 난제였던 "예외 처리 후 프로그램 종료" 문제를 해결한 후,

나는 예외 처리 개념에 통달했다는 자만에 빠졌다.

 

하지만 4주 차 미션의 요구사항

"사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, "[ERROR]"로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시 받는다."

를 해결하면서 바로 겸손해졌다..

 

3주 차에서 사용한 방식대로,

예외를 최상위 메서드 한 곳에서 처리하는 방식으로는,

입력을 다시 받을 메서드를 호출할 방법이 없었다.

 

예외 처리를 발생하는 각 지점에서 수행하고,

입력 메서드를 재귀적으로 호출함으로써 요구 사항을 만족시킬 수 있었다.

반복문으로 해결하는 방법도 공부를 했지만,

가독성 측면에서 재귀적 호출이 낫다고 판단했다.

 

공부한 내용을 기억하고 + 나누고자 아티클도 작성해보았다.

 

[Java] 예외처리 반복 - 올바른 입력값을 받을 때까지 (try-catch)

프로그램을 작성하다 보면 예외를 처리한 후, 예외가 발생된 메서드를 다시 실행해야하는 경우가 있습니다. 그것을 수행하는 몇 가지 방법에 대해 정리해보고자 합니다. 예외 처리의 기본적인

woojin.tistory.com

 

자만이 깨지면서 느낀 점은..

하나의 지식은 하나의 문제로 얻을 수 없다는 것이었다.

여러 문제를 다뤄봐야 비로소 하나의 깊은 지식이 완성된다는 것을 깨달을 수 있었다.

(책 하나만 읽은 사람이 제일 어설프다 그런 것과도 비슷한..)

 

 

 

 

프리코스 커뮤니티

이번 주에도 커뮤니티로부터 많은 것을 얻으려고 노력했다.

  • 주간 회고록 공유
  • 동료분들의 회고 10개 정독하기 (사실 읽다 보니 20개는 읽은 듯)
  • 피어 리뷰 10개 작성

다만 시간이 좀 부족해, 지난주처럼 토론 글을 모두 정독하지는 못 했다.

 

지난 주차 동안 꾸준히 리뷰에 참여했더니, 리뷰 속도가 많이 개선되었다.

빨리 하는 것이 중요한 것은 아니지만, 기본적인 로직을 이해하는 속도가 빨라지자

다른 곳에서 여유를 가질 수 있었다.

 

지난 리뷰들은 요구사항과 관련된 실수, 네이밍에 관한 조언 등

비교적 단순한 코멘트를 달았다면,

이번 리뷰에서는 객체의 상태가 꼭 필요한지, UI 로직이 잘 분리되었는지와 같은 고차원적인 부분에 대한 의견을 전달할 수 있었다.

무엇보다, 동료분들의 일주일 간의 노고가 깃든 코드에서 빛나는 부분을 찾아볼 수 있는 여유가 생겼고

힘이 되는 칭찬을 드리기 위해 나름대로 노력했다. 그게 참 좋았다.

내가 받은 리뷰를 통해 많은 자신감을 얻었기 때문에, 돌려드리고 싶었기 때문.

 

회고를 읽는 것은 너무 재밌었다.

비슷한 고민이 담긴 글을 보고 위로를 많이 구할 수 있었다.

그리고 내가 해보지 못한 생각들로부터 많은 인사이트를 얻을 수 있었다.

특히, 실수가 두려움의 대상이 아닌 성장의 시작이라는 관점이 크게 와닿았다.

 

 

아쉬운 점이 하나 있었다면..

맞리뷰 오신다고 했는데 잠수 타신 분들이.. (세 분이나..)

늦게라도 와주실 거라 믿습니다 ^^.. 사실 안 믿고요

 

그래도 많은 분들께서 맞리뷰 해주셔서 감사했습니다!

 

 

 

 


끝이라니.. 믿어지지 않고.. 많이 허전하겠지만,

일단 월드컵을 볼 생각에 무척 설레고요,

새롭게 공부를 시작할 생각에도 설렙니다.

 

모두 행복하세요!

 

감사합니다.

 

 

 

 

 

 

 

 

 

 

반응형

+ Recent posts