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

우테코 7기 프리코스 4주차 - 편의점

여유부릴 틈 없이 일주일을 보냈네요. 저에겐 정말 복잡하고 요구사항이 까다로운 문제였다고 생각합니다. 미션이 끝나고 커뮤니티에서 문제에 대해 토론하는걸 구경했는데, 정말 다양한 부분에서 의견이 갈리는 것을 보고 복잡한 문제가 맞긴 하다는 생각이 들었습니다.

📍 이번 미션에서의 목표

3주차에 이어서, 이번주도 저만의 목표를 세워보았습니다!

목표 1 : TDD (실패!)

이건 저번주의 목표이기도 했는데요, 저번주도 실패하고 이번주도 실패했네요 🌝

초반에는 단위 테스트도 같이 적어가면서 기능을 구현했는데요, 요구사항이 복잡하기도 하고 기존 설계를 계속 갈아엎게 되면서, TDD와는 멀어지게 되었습니다...

결국 구현을 완료하고 테스트코드를 작성했는데, 여러 테스트를 돌려보는 과정에서 결국 추가적인 여러 에러를 발견해서 뒤늦게 수정하기도 했습니다!

TDD와 가까워지기 참 어렵네요 😓

목표 2 : GPT 사용하지 않기

여러 개발 프로젝트 과정에서, GPT에 많이 의존할수록 코드 이해도가 떨어지고, 결과적으로 제가 작성한 코드가 아니기에 어떤 오류가 발생했을 때 이를 해결하기 굉장히 어려웠던 경험이 있습니다. 그래서 저는 특히 복잡한 구조일수록 생성형 AI에 중심 로직에 대한 코드 작성을 맡기는 것을 지양하고 있습니다!

이번 미션은 특히나 구조가 복잡하다고 생각했고, 주어진 요구사항을 꼼꼼히 지키며 스스로 코드를 작성하기 위해 생성형 AI를 사용하지 않는 것을 목표로 삼았습니다.

중심 로직을 모두 구현하고 주어진 테스트 코드를 통과할 때까지 생성형 AI를 사용하지 않고, 스스로의 힘으로 구현했습니다!

모두 내가 작성한 코드이다보니 오류가 발생한 부분을 찾거나, 로직을 수정할 때 수월했던 것 같습니다. (그래서 미션 마감 직전까지 열심히 수정했습니다 ㅎㅎ..) 의외로 메서드명, 변수명을 스스로의 힘으로 짓는게 정말 힘들었던 것 같네요. 개발 과정 내내 파파고를 항상 켜놓고 작업했습니다🦜

📍 설계

믿기지 않을 수 있겠지만 꽤 많은 시간을 고민한 결과물입니다,,

• 출력할 때 필요한 정보만 담아놓는 Dto들을 만들어봤습니다! 기존에 view가 model에 의존하지 않으면서 model의 내용을 출력하기 위해, model -> service -> controller -> view 이렇게 데이터를 전달했는데요, 다른 분들의 코드를 구경하다보니 DTO를 사용하여 출력하는 방법이 있다는 것을 알게 됐습니다! 이렇게 하면 view가 domain에는 접근하지 않으면서, 필요한 정보는 깔끔하게 뿌려줄 수 있다는 장점이 있는 것 같아요.

• 제가 설정한 domain 목록은 아래와 같습니다

  • 물품 정보와 재고를 저장하는 Product, 이러한 물품들을 저장하는 Products
  • 물품 하나에 대한 구매 정보를 저장하는 Purchases, 이러한 구매 목록을 저장하는 Purchases
  • 프로모션에 대한 정보를 저장하는 Promotion, 이러한 프로모션들을 저장하는 Promotions

• service를 두가지로 나눠봤습니다! 처음에 물품과 프로모션 목록을 읽어오고 저장하는 것은 프로그램 동작동안 한 번만 일어나고, 사용자로부터 주문을 받는 것은 여러 번 일어나기 때문에, 이 두 개를 기준으로 분리했습니다.

  • StoreService에서는 promotions.md와 products.md를 기반으로 객체들을 생성하여 저장합니다. 처음에 프로그램을 동작시킬 때 생성됩니다.
  • ProductService는 사용자의 주문을 처리하는 로직을 담당합니다. 사용자가 추가 구매를 할 때마다 새로운 ProductService가 생성됩니다.

• 이렇게 개발한 제 코드는.. 너무 복잡하다고 생각합니다🥶. 일단 service를 굳이 만들었어야 했나? 라는 생각이 들 정도로 도메인의 책임이 너무 강하고, 서로 엉켜있는 것 같습니다.. 더 좋은 설계 방법이 있겠지만 갈아엎기에는 시간이 부족하다고 판단해서 이대로 진행했습니다. 다른 분들의 멋진 코드를 구경하고 싶네요!

📍 고민 과정

🧶 3/4의 늪.. 그리고 디버깅 과정

원래 항상 늦게 제출하곤 했는데, 이번 미션은 꽤나 싸하게 느껴져서 일요일 3시에 열리자마자 바로 제출해봤습니다.

이제껏 로컬과 제출 결과가 항상 같았는데, 지원 페이지에서는 한 문제가 틀렸다고 떠서 많이 당황스러웠습니다.😵‍💫

우선 어떤 테스트가 웹상에서 틀리다고 하는건지 파악하기 위해, 모든 테스트를 하나씩 틀리게 설정해서 push해보았습니다.

이런식으로 주저리주저리.. 혼잣말 하면서 하나씩 테스트해본 결과, 파일에 있는 상품 목록 출력 테스트가 실패한다는 것을 확인할 수 있었습니다.

그래서 상품 출력과 관련해서 다양한 시도를 해보다가, products.md의 내용을 전부 지우고 제출했을 때 다른 테스트가 모두 통과하는 것을 확인했습니다.

어떤 원리인지는 모르겠지만, 기본으로 제공한 products.md를 기반으로 상품 목록을 읽어오게 고정했다고 이해했습니다. 저는 원래 products.md를 수정해서 테스트 코드가 통과하게 했어서, 테스트가 실패했던거였습니다.

그래서 기본 products.md를 기반으로도 테스트 코드의 결과가 나올 수 있도록 코드를 수정했습니다. ( products.md에 프로모션 재고가 존재하는 경우, 일반 재고가 따로 적혀있지 않아도 일반 재고에 대해 재고 없음을 출력해주니 해결됐습니다. )

처음에 제가 해석한대로 코드를 작성하는 과정에서, "기본 테스트가 통과하도록 기본 md를 제공해야 하는게 아닌가?"라는 생각이 들었는데, 그냥 제가 잘 못 해석한 것이라는 것을 뒤늦게 깨달았네요..(사실 md파일을 수정할 수 있다고 적혀 있어서 더 헷갈렸던 것 같습니다💦)

🧾 영수증 포맷팅 과정

아무리 포맷팅을 해봐도 영수증이 예쁘게 정렬이 안돼서, 검색도 열심히 해보고 이 부분은 지피티에게도 물어봤습니다.

그런데 인텔리제이 콘솔창에서 한글 폭과 영어 폭이 다르기 때문에 예쁘게 정렬이 안 되는 것이라는 것이라고 판단하고, 고정폭이 적용되는 터미널에서 출력 결과를 복붙해가며 개발했습니다.

제공된 테스트 코드를 보니까 어차피 공백은 전부 지우고 테스트하는 것 같아서, 이정도로 만족했습니다.

📍 성찰

리뷰로 받은 피드백 적용

저번 미션에서 받은 리뷰 내용에 대해 많이 고민하거나 적용해보지 못한 것 같습니다. 이번주 미션은 구현할 수 있을지조차 확신하지 못했기 때문에, 우선 돌아가는 쓰레기를 만드는 것에 집중했었고, 끝까지 오류를 수정하고 예외 상황을 찾고 하다보니 시간이 부족했던 것 같습니다.. 시간관리를 조금 더 잘했더라면 더 성장할 수 있지 않았을까 하는 아쉬움이 남네요.

역할 분리

아무래도 역할 분리를 제대로 하지 못했다는 생각이 듭니다. 도메인이 160줄, 150줄 이렇게 찍히기도 하고, getter를 남발하고 있고, 메서드 수도 너무 많다보니 뭔가 잘못됐다..라고 느끼긴 했는데 여기서 갈아엎으면 되돌아올 수 없을 것 같아서 그냥 이 상태로 마무리했습니다.
제가 작성한 코드이지만, 주석을 남기지 않으면 메서드의 역할이 헷갈리기도 하더라구요. 앞으로는 의식적으로 역할 분리를 더욱 철저히 해서, 과중한 책임을 지지 않도록 노력해야겠습니다.

📍 마무리

4주동안 열심히 달려오면서 아쉬운 순간도 많았지만, 정말 많이 성장했다고 생각합니다. 그동안 못 했던 취미생활도 하면서 프리코스를 통해 배운 내용들 까먹지 않도록 다시 정리해야겠습니다! 프리코스를 통해 새롭게 배운 내용들을 적용해보면서 1주차 문제를 다시 풀어봐도 좋을 것 같다는 생각이 드네요.

1차 합격하면 너무 좋겠지만! 불합격하더라도 이번 경험을 통해 많이 성장했다는 사실에 만족하며, 다음 기회를 위한 발판으로 삼아야겠습니다.