[우아한 테크코스 6기 프리코스] 4주차 회고록

4주 차도 어느덧 끝이 났네요. 이번 주는 지난 3주간 배운 내용들을 최대한 미션에 적용해 보고자 노력했던 한 주였습니다. TDD에 대한 이해도 역시 높아진 것 같아 자신감 있게 미션을 진행했습니다!

특히 지난 코수타에서 준 코치님께서 말씀하신 부분에 대해서 많이 고민을 했어요. ‘서비스의 핵심을 파악하고, 이를 위한 코드를 먼저 구현해보아라’라는 것인데요, 사실 지난 3주간 배웠던 TDD 개발 방법과는 상반되는 말씀이라고 생각했습니다. 테스트 코드를 작성하기 이전 실제 코드를 작성하라는 것처럼 들렸거든요. 그래서 그 의미를 정확히 짚어보고자 노력했습니다.

🌱시스템의 핵심을 파악하라?

준 코치님께서 말씀하신 핵심을 파악하고 빠르게 로직을 작성해 보라는 것의 의미가 무엇인지 고민했습니다. 저는 다른 분들이 말씀하신 ‘예쁘지만 돌아가지 않는 프로그램을 만드는 것이 아닌, 돌아가는 쓰레기를 만들라는 것’의 의미가 아닌가 생각했습니다. ‘즉 빠르게, 생산성 있는 코드를 작성할 줄 알아야 한다’라는 말로 해석했습니다,

저는 첫 3주간 TDD에 대한 학습으로, 코드를 작성하는 데 있어 ‘테스트 코드 작성’ → ‘실제 코드 작성’ → ‘리팩토링’ → ‘로직의 병합’ 순으로 코드를 작성했습니다. 여기서 항상 드는 생각은 ‘너무 어물쩍거린다’는 것이었습니다. 도메인 로직 리팩토링을 다 하고 로직을 병합하는 탓에, 실질적으로 서비스를 만들어 내는 상황은 제일 마지막 이었던 것이었죠. 스스로 이 과정을 돌아보며 ‘우선 돌아가는 쓰레기를 만들자’는 생각하였고, 어떻게 ‘빠르게 요구사항을 충족시킬 수 있을까?’ 고민했습니다.

일단 이번 미션의 핵심 기능을 정리해 봤습니다.

1. 날짜를 입력
2. 메뉴를 입력
3. 이벤트 플래너 결과 출력

핵심 기능을 정리해도 사실 감이 잡히진 않았습니다. 이 기능을 만들더라도, 요구사항을 충족하기 위해서는 자세한 도메인 로직들이 필요하고, 그렇다면 이전의 코드를 작성하는 방식과 다를 바 없다고 생각했거든요.

스스로 잘 모르는 설계 방식이 있나 많이 찾아보기도 했습니다. 과정에서 BDD와 DDD같은 처음 들어보는 개발 방법론에 대해서도 공부하기도 했어요. 하지만 빠르게 요구사항을 충족시킨다는 목적을 해결해 주는 그런 방법론을 찾을 순 없었습니다.

[개발 상식] BDD와 DDD

그래서 준 코치님께서 말씀하신 부분을 스스로의 방식으로 해석을 했습니다. 코드를 작성하는 것은 그림을 그리는 것과 같다고 생각했어요. 그림을 그리기 전 밑그림을 그리듯 코드를 작성하기 전 러프하게 코드를 작성했고요, 그림의 형태를 다 그리고 나서 디테일한 부분을 잡듯이 프로그램의 형태를 다 잡고 리팩토링을 하는 것이죠. 그리고 이를 이번 미션에서 적용해 보았습니다. 결과는? 확실히 요구 사항에 집중할 수 있었고, 빠르게 서비스가 완성되었습니다!

1. 러프하게 코드를 작성하며 서비스의 흐름을 파악한다.
2. 서비스가 요구하는 사항을 겨우 충족할 정도의 코드를 작성한다. 즉 형태를 잡는다.
3. 리팩토링을 통해 코드 가독성을 높인다. 디테일을 잡는다.

코드의 구체적인 사항을 적지 않고, 텅 빈 메서드로 전체적인 서비스의 흐름을 한 선으로 이으며 러프하게 코드를 작성했습니다. 이 과정은 ‘기능 구현 목록 작성’과 일맥상통하는 행위였는데요, 이를 단순히 README 목록 작성으로 끝나는 것이 아닌 코드를 짜는 행위까지 더하게 되었고, 이를 통해 확실히 서비스의 핵심 흐름을 잡을 수 있었다는 느낌을 받을 수 있었습니다. 이 덕분에 도메인 로직에 충실하면서도, 처음 잡아놓은 흐름 덕분에 핵심을 잃어버리지 않을 수 있었답니다.

그리고 서비스가 요구하는 사항을 겨우 충족할 정도의 코드를 작성함에 따라, 테스트 코드 역시 간결해졌습니다. 필요 이상의 테스트 코드를 작성함으로써 시간을 많이 뺏기곤 했는데요, 도메인 로직에 대한 엣지 케이스를 우선적으로 만들면서 테스트 본질에 충실한 코드를 작성할 수 있었고, 덕분에 조금 더 빠르게 서비스를 개발할 수 있었다고 생각합니다!

그리고 이 과정에서 이전과 달랐던 가장 큰 부분은, 리팩토링 이전 서비스가 완성된다는 것이었습니다. 나름 굴러가는 쓰레기를 먼저 만들 수 있었다는 것이죠! 틈틈이 리팩토링 한다는 것이 불필요한 행위임을 깨닫게 되었습니다. 서비스를 만든 후 리팩토링을 함으로써 불필요한 public 객체를 줄일 수 있기도 했구요! 이렇게 시스템의 핵심을 파악함으로써 생산성 있는 코드를 만들 수 있는 역량에 대해 느낀 것 같았습니다!

🌱객체를 객체스럽게?

객체 지향의 의미를 점점 알아가면서, 스스로 객체 지향을 더 객체 지향스럽게 코드를 만들기 위해서 지금까지 노력했습니다. 의존성, 캡슐화, 다형성 등 이러한 부분들을 조금씩 더 신경 쓰고자 할 때마다 자연스럽게 ‘설계’에 대해서 공부하게 되었습니다. 마치 객체 지향 이라는 것이 ‘좋은 설계’의 방법론인 것처럼 느껴지더라고요. 그래서 저는 객체 지향을 더 깊게 이해하기 위해선 설계를 공부해야 할 필요성을 느꼈고, 이번 주부터 ‘쉽게 배워 바로 써먹는 디자인 패턴’이라는 책을 읽으며 한 주를 보내고 있답니다!

특히 이번 주 미션은 저번 미션보다 더욱 복잡하다고 느껴졌었는데요, 개인적인 생각으로는 ‘모델 수의 증가’라고 생각했습니다. 이전 미션에서 단일의 모델을 사용한 것과 다르게 처음으로 2개의 모델을 만들었거든요. 2개의 모델로 시스템을 구성하려고 하니, 책에서 배운 패턴들을 응용할 수 있겠다는 생각이 들었습니다. ‘예약 날짜’ 클래스와 ‘예약 메뉴’ 클래스를 Controler라는 알고리즘을 만들어 App에서 실현하고자 했습니다. 완전히 올바르게 적용했다고 할 순 없겠지만, 나름 ‘빌더 패턴’을 구현하려고 노력했답니다!

[디자인 패턴] 빌더(Builder) 패턴

이렇게 객체 지향스러운 코드를 만들기 위해 디자인 패턴을 공부하면서 새롭게 안 사실이 또 하나 있었습니다. 바로 ‘프로토타입 패턴’이라는 것이죠. 프로토타입? 자바스크립트를 공부할 때 많이 들어봤었는데, 자바스크립트에 기본적으로 내장되어 있는 패턴이라는 것 역시 이번에 알면서, 자바스크립트가 ‘다중 패러다임 언어’라는 것을 또 한번 느꼈답니다! 단순히 함수형 프로그래밍이 아니라는 사실을 배운 것이죠..!

[디자인 패턴] 프로토타입(Prototype) 패턴

이렇게 객체 지향을 더욱 객체 지향스럽게 만들려는 노력으로 소프트웨어 역량을 길렀다고 생각합니다! 좋은 동료가 되기 위한 길로 한 발 더 내딛은 것 같은 느낌입니다!

 

제가 작성한 4주차 미션 코드 저장소입니다.

GitHub - lurgi/javascript-christmas-6-lurgi: 4주 차 미션