[우아한테크코스] 우테코 프리코스 6기 4주차 크리스마스 프로모션 미션 회고

개인적으로는 미션 수행을 통해 성장한 과정을 기록하고,
누군가에게는 이 글이 도움이 되었으면 하는 마음입니다 :)

 

🛠️ 4주 차 결과물

4주 차 미션 : 크리스마스 프로모션 PR

프로모션 실행 화면과 테스트 통과 화면

 

 

📮 4주 차 메일 내용

1️⃣ 4주 차 미션의 목표

3주 차 미션의 목표는 함수 분리와 함수별 테스트 작성이었다. 그리고 지난 3주 차 목표가 4주 차까지 이어지기에 (1) 클래스(객체)를 분리하는 연습, (2) 도메인 로직에 대한 단위 테스트 작성 연습 두 가지를 더 연습하라는 설명이 있었다. 다행이었다. 뭔가 더 추가가 되었다면 미션 난이도까지 겹쳐져 힘들었을 텐데 지금까지 배운 내용을 더 '고도화'하면 되겠다 생각했다. 

 

2️⃣ 클래스(객체) 분리하는 연습

특히 클래스(객체)를 분리하는 것에 대해 더 깊게 고민해 볼 수 있도록 예시 클래스와 요구사항이 추가되었다. 미션을 하면서 클래스의 역할과 책임을 생각하고, 클래스를 작성할 때는 도메인 로직에 집중하는 방향으로 구현하는 것, 그리고 UI는 도메인 로직과 분리하는 방향으로 생각하라는 조언이 있었다. 이는 3주 차 때 연습했던 것이었어서 4주 차 미션에서는 '더 잘하는 연습'을 하리라 결심했다.

 

 

🌳 지난 3주 차 공통 피드백

아래는 3주 차 미션 마감 후, 모든 프리코스 참여 인원에게 발송된 공통 피드백이다. 확실히 1주 차 때를 생각하면 더 클린코드와 객체지향 프로그래밍, 그리고 테스트 코드에 관련된 깊은 조언이 있었다. 지난 미션 때 아쉬웠던 부분인 테스트코드 리팩토링과 필드 수 줄이기를 더 연습해 보기로 했다. 그리고 지난 미션에 이어 이번에도 객체 지향적으로 생각하기, 빈틈없이 예외 처리를 잘하리라 마음먹었다.

1. 함수(메서드) 라인에 대한 기준
2. 발생할 수 있는 예외 상황에 대해 고민한다
3. 비즈니스 로직과 UI 로직을 분리한다
4. 객체의 상태 접근을 제한한다
5. 객체는 객체스럽게 사용한다
6. 필드의 수를 줄이기 위해 노력한다
7. 성공하는 케이스뿐만 아니라 예외에 대한 케이스도 테스트한다
8. 테스트 코드도 코드다
9. 테스트를 위한 코드는 구현 코드에서 분리되어야 한다
10. 단위 테스트하기 어려운 코드를 단위 테스트하기

 

 

🤚 미션에 앞서,

1️⃣ 기능 목록 만들기

미션은 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 세 가지로 구성되어 있다. 특히 주목해야 할 점은 기능을 구현하기 전에 기능 목록을 만든다는 것. 그리고 기능 단위로 커밋하는 방식으로 진행한다. 

 

2️⃣ 제출 전 테스트 필수

기능 구현을 모두 정상적으로 했더라도 요구 사항에 명시된 출력값 형식을 지키지 않을 경우 0점으로 처리된다. 기능 구현을 제대로 했더라도 출력 값 형식을 지키지 않으면 0점이라는 소리다. 기능 구현을 완료한 뒤 테스트를 실행했을 때 테스트가 실패할 경우 0점으로 처리되므로, 반드시 확인 후 제출한다. 필자는 Node 환경에서 프로그램이 잘 돌아가는지 확인하고, 로컬 테스트 코드 통과까지 확인했다.

 

뿐만 아니라, 제출 가능 기간에는 미리 PR을 올리고 지원하기 플랫폼의 예제 테스트까지 미리 돌려보았다. 그렇지 않으면 마감이 몇 시간 남지 않은 상태에서 추측이 어려운 에러와 기약 없이 싸워야 하니 미리미리 확인하자.

 

3️⃣ Node 버전 확인 필수

테스트 패키지 설치를 위해 Node.js 버전 18.17.1 이상이 필요하다. 본인 로컬의 Node 버전이 몇인지 꼭 확인 후 미션을 진행하자. 참고로 Node 버전 확인은 'node --version'으로 확인 가능하며, 업데이트는 Node.js 공식 사이트를 참고하거나, 아래와 같이 'nvm install'로 특정 Node 버전을 설치할 수 있다.

 

Node 버전 설정 화면

 

4️⃣ (중요) 미션 제출 방법

이번 미션부터는 새로운 미션 제출 방법이 적용되었다. 비공개 저장소를 생성 후, 우테코 계정을 collaborator로 초대하고, 지원 플랫폼에 PR 주소가 아닌 비공개 레포 주소를 첨부하는 것이다. 지난 미션들은 모두 지난 기수들에서도 진행되던 미션인 데다가 미션 진행 과정 또한 누구에게나 공개가 되어 있어 마음만 먹으면 코드를 베껴서라도 제출할 수 있었지만, 이번 미션은 철저히 비공개로 진행되어 진짜 본인의 실력을 보고자 하는 것 같았다.

 

 

🎄 기능 요구 사항

1️⃣ 크리스마스 프로모션 미션 설명

미션에 대한 자세한 내용은 우테코 프리코스 레포에 있으니 참고하길 바라며, 간단히 미션 설명을 하자면 고객들이 식당에 방문할 날짜와 메뉴를 미리 선택하면 정보가 담긴 이벤트 플래너를 보여주는 프로모션을 개발하는 것이다.

 

4주 차 미션을 받기 전, 코수타(코치와 수다 타임)에서 코치님이 이번 미션은 3주 차보다 훨씬 어려울 것이라고 하셨는데, 메일을 받아보니 정말 '뜨악'이었다. 요구사항이 꽤 많았다. 그래도 그나마 나았던 것(?)은 특이하게 이메일 형식으로 요구사항을 설명해 친절하게 느껴졌다는 것. 아래와 같은 형식으로 말이다.

 

미션 요구사항 설명 인트로

 

근데 어찌보면 딱딱한(?) 요구사항보다 이렇게 메일로 받으니까 진짜 우아한형제들 개발팀의 개발자로 일하는 느낌이 들어 좋았다. 그래서 내친김에 README도 이메일 형식으로 써보았다. 2주 차 공통 피드백에서 "해당 프로젝트가 어떤 프로젝트인지, 어떤 기능을 담고 있는지" 기술하라는 말이 떠오르기도 했기 때문.

 

2주 차 공통 피드백 일부

 

작성한 README 일부

 

2️⃣ 이벤트 플래너 실행 결과 예시

완성된 '이벤트 플래너'는 아래와 같이 출력되어야 한다. 다만, 요구사항 메일에 "기대하는 예시를 한 개만 들어서 설명했지만, 더 다양한 사례가 있을 것으로 예상됩니다."라고 기재된 것처럼 요구사항과 출력 형식을 어느 정도 지키면서 다양한 구현을 열어둔 것 같다.

 

안녕하세요! 우테코 식당 12월 이벤트 플래너입니다.
12월 중 식당 예상 방문 날짜는 언제인가요? (숫자만 입력해 주세요!)
3
주문하실 메뉴를 메뉴와 개수를 알려 주세요. (e.g. 해산물파스타-2,레드와인-1,초코케이크-1)
티본스테이크-1,바비큐립-1,초코케이크-2,제로콜라-1
12월 3일에 우테코 식당에서 받을 이벤트 혜택 미리 보기!
 
<주문 메뉴>
티본스테이크 1개
바비큐립 1개
초코케이크 2개
제로콜라 1개
 
<할인 전 총주문 금액>
142,000원
 
<증정 메뉴>
샴페인 1개
 
<혜택 내역>
크리스마스 디데이 할인: -1,200원
평일 할인: -4,046원
특별 할인: -1,000원
증정 이벤트: -25,000원
 
<총혜택 금액>
-31,246원
 
<할인 후 예상 결제 금액>
135,754원
 
<12월 이벤트 배지>
산타

 

이번 미션은 지난 3주 차 로또 미션보다 훨씬 더 요구사항이 복잡하고 많기 때문에 이것저것 자잘하게 챙길 것이 많았다. 그래서 명세를 쓰고도 기능 구현을 하면서 요구사항 문서를 계속 계속 보면서 놓친 것이 없는지 체크했다.

 

아래는 필자가 해석한 요구사항에 따라 구현한 방식을 써보겠다.

 

3️⃣ 크리스마스 프로모션 기능 요구 사항

✅ 이벤트 목표
1. 중복된 할인과 증정을 허용해서, 고객들이 혜택을 많이 받는다는 것을 체감할 수 있게 하는 것
2. 올해 12월에 지난 5년 중 최고의 판매 금액을 달성
3. 12월 이벤트 참여 고객의 5%가 내년 1월 새해 이벤트에 재참여하는 것

 

↪️ 이벤트 목표는 왜 써있는걸까..? 생각해 보았다. 첫 번째는 일단 이 미션의 취지를 알리는 것이겠거니 했고, 두 번째로는 1월 이벤트도 있으니 코드를 더 확장성 있게 짜라는 것인가 싶었다. 세 번째로는 최종 코딩테스트가 새해 이벤트일까..? 스포일까..? 생각했다.

 

✅ 12월 이벤트 계획
- 크리스마스 디데이 할인
 - 이벤트 기간: 2023.12.1 ~ 2023.12.25
 - 1,000원으로 시작하여 크리스마스가 다가올수록 날마다 할인 금액이 100원씩 증가
 - 총주문 금액에서 해당 금액만큼 할인 (e.g. 시작일인 12월 1일에 1,000원, 2일에 1,100원, ..., 25일엔 3,400원 할인)
- 평일 할인(일요일~목요일): 평일에는 디저트 메뉴를 메뉴 1개당 2,023원 할인
- 주말 할인(금요일, 토요일): 주말에는 메인 메뉴를 메뉴 1개당 2,023원 할인
- 특별 할인: 이벤트 달력에 별이 있으면 총주문 금액에서 1,000원 할인
- 증정 이벤트: 할인 전 총주문 금액이 12만 원 이상일 때, 샴페인 1개 증정
- 이벤트 기간: '크리스마스 디데이 할인'을 제외한 다른 이벤트는 2023.12.1 ~ 2023.12.31 동안 적용

 

↪️ 이번 미션의 핵심이라고 볼 수 있다. 여러 할인이 조건에 따라 다르게 적용되어야 한다. 각 할인 이벤트를 적용하기 위해서는 요일, 메뉴 타입, 날짜, 총 주문 금액 등등 고려해야 할 것이 많은데 이 고려 대상이자 기준으로 사용되는 것들을 MVC 중 Model로 두기로 했다. 또한 유심히 봐야 할 것은 문제에서 말하는 주말은 토-일이 아니라, 금-토라는 것이다.

 

✅ 혜택 금액에 따른 12월 이벤트 배지 부여
- 총혜택 금액에 따라 다른 이벤트 배지를 부여합니다.
- 이 배지는 2024 새해 이벤트에서 활용할 예정입니다.
- 배지에 따라 새해 이벤트 참여 시, 각각 다른 새해 선물을 증정할 예정입니다.
 - 5천 원 이상: 별
 - 1만 원 이상: 트리
 - 2만 원 이상: 산타

 

↪️ 위에서 적용된 이벤트 혜택 금액에 따라 각각 다른 배지를 부여한다. 이때 총 혜택 금액이 5천 원 이하이거나 아예 없을 경우에는 '없음'이라고 표기한다.

 

✅ 고객에게 안내할 이벤트 주의 사항
 - 총주문 금액 10,000원 이상부터 이벤트가 적용됩니다.
 - 음료만 주문 시, 주문할 수 없습니다.
 - 메뉴는 한 번에 최대 20개까지만 주문할 수 있습니다. (e.g. 시저샐러드-1, 티본스테이크-1, 크리스마스파스타-1, 제로콜라-3, 아이스크림-1의 총개수는 7개)

 

↪️ 위 요구사항에서 눈여겨보아야 할 지점은 '고객에게 안내할' 이벤트 주의사항이라는 것이다. 대놓고 요구사항이라 쓰여있지 않지만 어쨌든 해당 상황일 때 고객에게 알려주어야 한다.

 

필자는 총 주문 금액이 10,000 미만인 경우에는 일단 주문은 가능하게 하고 이벤트만 적용되지 않게 했다. 그리고 아래와 같이 이벤트 플래너 하단에 안내 메시지를 덧붙였다. '왜 이벤트 적용이 안 됐지?'라는 사용자의 궁금증을 풀어주고 싶었다.

 

총주문금액 10,000원 미만일 경우는 안내

 

반면에 음료만 주문하거나 메뉴가 20개가 초과할 경우는 주문조차 할 수 없다고 기재되어 있으니, 아래와 같이 에러로 처리해 해당 부분부터 다시 입력받도록 했다.

 

음료만 주문할 경우, 20개 이상 주문할 경우는 에러

 

✅ '12월 이벤트 플래너' 개발 요청 사항
- 고객들이 식당에 방문할 날짜와 메뉴를 미리 선택하면 이벤트 플래너가 주문 메뉴, 할인 전 총주문 금액, 증정 메뉴, 혜택 내역, 총혜택 금액, 할인 후 예상 결제 금액, 12월 이벤트 배지 내용을 보여주기를 기대합니다.
- 12월 중 식당 예상 방문 날짜는 언제인가요? (숫자만 입력해 주세요!)
 - 방문할 날짜는 1 이상 31 이하의 숫자로만 입력받아 주세요.
 - 1 이상 31 이하의 숫자가 아닌 경우, "[ERROR] 유효하지 않은 날짜입니다. 다시 입력해 주세요."라는 에러 메시지를 보여 주세요.
 - 모든 에러 메시지는 "[ERROR]"로 시작하도록 작성해 주세요.
- 주문하실 메뉴와 개수를 알려 주세요. (e.g. 해산물파스타-2,레드와인-1,초코케이크-1)
 - 고객이 메뉴판에 없는 메뉴를 입력하는 경우, "[ERROR] 유효하지 않은 주문입니다. 다시 입력해 주세요."라는 에러 메시지를 보여 주세요.
 - 메뉴의 개수는 1 이상의 숫자만 입력되도록 해주세요. 이외의 입력값은 "[ERROR] 유효하지 않은 주문입니다. 다시 입력해 주세요."라는 에러 메시지를 보여 주세요.
 - 메뉴 형식이 예시와 다른 경우, "[ERROR] 유효하지 않은 주문입니다. 다시 입력해 주세요."라는 에러 메시지를 보여 주세요.
 - 중복 메뉴를 입력한 경우(e.g. 시저샐러드-1,시저샐러드-1), "[ERROR] 유효하지 않은 주문입니다. 다시 입력해 주세요."라는 에러 메시지를 보여 주세요.
 - 모든 에러 메시지는 "[ERROR]"로 시작하도록 작성해 주세요.
- 주문 메뉴의 출력 순서는 자유롭게 출력해 주세요.
- 총혜택 금액에 따라 이벤트 배지의 이름을 다르게 보여 주세요.
- 총혜택 금액 = 할인 금액의 합계 + 증정 메뉴의 가격
- 할인 후 예상 결제 금액 = 할인 전 총주문 금액 - 할인 금액
- 증정 메뉴
 - 증정 이벤트에 해당하지 않는 경우, 증정 메뉴 "없음"으로 보여 주세요.
- 혜택 내역
 - 고객에게 적용된 이벤트 내역만 보여 주세요.
 - 적용된 이벤트가 하나도 없다면 혜택 내역 "없음"으로 보여 주세요.
 - 혜택 내역에 여러 개의 이벤트가 적용된 경우, 출력 순서는 자유롭게 출력해주세요.
- 이벤트 배지
 - 이벤트 배지가 부여되지 않는 경우, "없음"으로 보여 주세요.

 

↪️ 일단 요구사항이 매우 길어 보이지만, 친절하게 예외 상황과 메시지까지 적혀있기 때문이라고 본다. 사실 로또 미션에서는 이렇게나 예외 상황에 대해 상세하게 써주지 않아 내가 일일이 사용자의 인풋을 고려해 예외 처리를 해주었는데, 이번 미션은 상대적으로 친절한 편이라고 생각했다. 그리고 감사하게도 에러 메시지를 모두 통일해 주어서 작업할 때 덜 헷갈렸던 것 같다.

 

 

🚨 프로그래밍 요구 사항 - 실행 환경

✅ Node.js 18.17.1 버전에서 실행 가능해야 한다.

👉 Node 버전 체크 필수다. 작업할 때 확인했더라도 제출하기 직전에 다시 한번 해당 버전에서 잘 돌아가는지 확인하자.

 

✅ 프로그램 실행의 시작점은 App.js의 run 메서드다.

👉 App.js의 play() 메서드로 시작했던 지난 미션들과는 달리, 이번 미션은 게임이 아니므로 run()으로 시작한다. 매 미션마다 실행 환경이나 요구 사항이 완전히 똑같지 않을 테니 이미 알고 있는 것이라도 다시 읽어보는 것이 좋겠다.

 

✅ package.json을 변경할 수 없고 외부 라이브러리(jQuery, Lodash 등)를 사용하지 않는다. 순수 Vanilla JS로만 구현한다.

👉 1주 차 공통 피드백에 나와 있듯이 이제는 자연스럽게 ESLint와 Prettier를 사용한다. 그리고 변경된 package.json 내역은 굳이 push 하지 않았다. (혹은 전역 설정을 해도 좋다.)

 

✅ JavaScript 코드 컨벤션을 지키면서 프로그래밍한다.

👉 Airbnb 코드 컨벤션을 하나하나 보고 따르기에는 너무 번거로우므로 ESLint와 Prettier를 설정해서 컨벤션을 맞추었다.

 

✅ 프로그램 종료 시 process.exit()를 호출하지 않는다.

👉 보통 프로그램을 종료할 때 Console.Close()나 process.exit()를 사용하고는 했지만, 여기서는 메서드를 호출하지 않는다. 지난 1주 차 미션에서는 게임 종료 시 '게임 종료' 문구를 출력했고, 2주 차는 에러를 발생시키고 그대로 애플리케이션이 종료되도록 했다. 그리고 3주 차, 4주 차는 해당 부분부터 다시 입력을 받는 형식으로 구현한다.

 

✅ 프로그램 구현이 완료되면 ApplicationTest의 모든 테스트가 성공해야 한다. 테스트가 실패할 경우 0점 처리한다.

👉 이번 미션의 ApplicationTest는 총 4개의 테스트였고, 이 네 가지 테스트를 모두 통과해야 한다.

 

✅ 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다.

👉 디폴트로 있던 파일(ApplicationTest.js, package.json, package-lock.json 등)과 코드, 폴더는 별다른 요구사항이 없기에 굳이 건들지 않았다. 혹시나 지원 플랫폼 예제 테스트에 통과하지 못할까 봐 굉장히 조심스러웠던 것도 있다.

 

✅ indent(인덴트, 들여 쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다. 

👉 사실 함수 하나에 15줄 이상 넘어가고 depth가 많아지면 한 가지 일을 하지 않을 가능성이 높다. 따라서 indent depth를 줄이고자 한다면 함수 또는 메서드를 분리하면 된다. 더불어, 많은 이들이 depth에 대해 커뮤니티에 질문을 남겼는데, 예를 들어 while문 안에 if문이 있으면 들여 쓰기는 2이다.

✅ Jest를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다. 

👉 되도록 모든 메서드를 테스트하고자 했다. 특히 작은 단위는 꼭 테스트해서 검증해야 추후 컨트롤러에서 터지면 안 되니까.

 

✅ 함수(또는 메서드)의 길이가 15라인을 넘어가지 않도록 구현하며, 함수(또는 메서드)가 한 가지 일만 잘하도록 구현한다.

👉 이 요구사항이 있어서 더 의식적으로 좋은 코드를 쓸 수 있게 된 것 같다. 더불어, 이는 아래와 같이 ESLint 상에서 설정하면 좋다.

// .eslintrc.cjs
'max-lines-per-function': ['error', { max: 15 }],

✅ else를 지양한다. 

👉 if 조건절에서 return 하면 굳이 else를 사용하지 않아도 된다. 다만, 무조건적으로 지양한다기보다 때로는 if/else와 switch문을 사용하는 것이 더 깔끔해 보일 수 있어서 이는 고민해 보라고 한다.

 

✅ 도메인 로직에 단위 테스트를 구현해야 한다. 단, UI(Console.readLineAsync, Console.print) 로직에 대한 단위 테스트는 제외한다.

👉 여기서 중요한 건 핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 구분한다는 것이다. 이번 미션에서는 지난 2,3 주 차와는 다르게 예시 테스트 코드가 주어지지 않았다.

 

✅ 사용자가 잘못된 값을 입력할 경우 throw문을 사용해 예외를 발생시킨다. 그런 다음, "[ERROR]"로 시작하는 에러 메시지를 출력하고 해당 부분부터 입력을 다시 받는다.

👉 지난 미션과 같이 예외 상황에서는 에러 메시지 출력 후, 애플리케이션을 종료시키는 것이 아니라 해당 부분부터 다시 입력받아야 한다.

 

 

➕ 4주 차에 추가된 요구사항

✅ 제공되는 InputView, OutputView 객체를 활용해 구현한다.

👉 이번에는 InputView 클래스와 OutputView가 주어졌고, 입출력을 담당하는 객체를 별도로 구현하도록 했다. 지난 미션들보다 점점 역할 분리에 대해 강조하고 있는 듯하다. 다만, 이 두 개의 파일 경로나 메서드 인자, 이름은 필요에 따라 추가하거나 변경할 수 있었다.

 

 

🚨 프로그래밍 요구 사항 - 라이브러리

✅ @woowacourse/mission-utils의 Random 및 Console API를 사용하여 구현해야 한다.

✅ 사용자의 값을 입력받고 출력하기 위해서는 Console.readLineAsync, Console.print를 활용한다.

👉 지난 미션들과 다른 점은 이번 미션에서는 Random API를 사용하지 않는다는 것이다.

 

 

📚 미션을 통해 적용하고 배운 점

1️⃣ 4주 차 계획하기

지난 3주 차 때 아쉬운 점 중 하나로 '시간 관리'를 꼽았었다. 미션의 난이도는 높아졌는데 시간을 효율적으로 잘 사용하지 못해서 마감까지 매우 조급하게 달렸던 기억이 있어, 이번 4주 차는 아래와 같이 눈에 보이게 계획하기로 했다.

 

노션에 계획하기

 

사실 미션이 끝난 지금 돌아보면 계획의 1/3 이상은 지켜지지 않았지만 그래도 눈에 보이게 정해두니 뭔가 마음이 편안해지는 느낌이었다. 뭔가 지치려고 할 때 이 계획을 보면 어서 해야겠다는 동기부여가 되기도 했다.

 

2️⃣ 설계에 시간들이기

지난 3주 차 미션 직후, 코수타 시간에 코치님이 '가장 중요한 것을 움직이는 가장 작은 버전부터 만들어라'라는 조언에 따라 체크리스트를 만들었다. 급하다고 기능 구현부터 막 하기보다, 이 애플리케이션의 핵심 기능과 로직을 생각해 보자는 것이다. 

 

체크리스트에 따라 도메인부터 설계

 

그래서 위와 같이 컨트롤러와 서비스 레이어에 포함될 도메인 영역부터 설계했다. 즉, 이 애플리케이션을 움직이는 객체들부터 각각 정의한 것이다. 예를 들어, Menu.js에서는 메뉴의 이름, 가격, 타입이 필요할 테고, Discount.js에서는 각 할인을 다루는 메서드들이 필요할 테니 쭉 적어 내려갔다.

 

아래와 같이 적어 내려가니 방대하게만 느껴졌던 핵심로직이 조각조각으로 붙여지며 구현하기가 편해졌다. 

 

✅ menu: 메뉴 단일로 검증하는 것
 - 하나의 메뉴가 유효한가?
 - 메뉴가 메뉴판에 있는가?
 - 개수가 양의 정수인가?

✅ order: 메뉴들을 모아놓고 봤을 때 아는 것
 - 중복으로 입력했는가?
 - 음료만 주문했는가?
 - 20개를 초과했는가?

 

이렇게 쪼개고 나니, 첫 회사 팀장님의 업무 조언이 생각났다. "업무가 많다고 느껴지면 왕돈가스를 썰듯이 하나하나 쪼개고, 쪼갠 것들을 차근차근 쳐내보세요. 왕돈가스도 썰지 않으면 어떻게 먹지 막막하지만 막상 쪼개보면 먹을만한 것처럼, 일도 쪼개면 생각보다 할만하다는 것을 느낄 거예요."

 

3️⃣ 서비스 레이어의 클래스 네이밍

지난 미션과 마찬가지로, 이번에도 MVC 패턴에 Layered Architecture을 적용했기에 컨트롤러의 역할 부담을 덜기 위해 서비스 레이어를 추가했다. (상세 과정은 아래에서 추가 설명 예정)

 

이 서비스 레이어 이름에 대해 고민하다가 어떤 영상을 접하게 되었는데, 서비스 레이어의 네이밍에는 ___Service로 짓는 것보다 다른 네이밍을 추천한다고 한다. 이유는 서비스 레이어가 진짜 유저 서비스일 확률이 아주 낮기 때문이다. (참고: Service에 너무 많은 책임 어떻게 관리할까? + 클래스 네이밍 고민)

 

3주차와 4주차 서비스 레이어 네이밍 변화

 

이전 로또 미션에서는 서비스 레이어를 LottoService로 짓고, 뭔가 '서비스'라는 방대한 개념을 단순 애플리케이션 내 파일 이름으로 지어버리는 게 맞을까 라는 고민이 있었다. 이에 4주 차에는 서비스 레이어 파일명을 'EventProcessor'라고 지었다. 비즈니스 로직을 담당하고 사용자에게 제공할 기능을 구현하는, 즉 프로그램의 프로세스를 담당하는 느낌을 주고 싶었다.

 

4️⃣ 자바스크립트 내장함수의 세계

자바스크립트 내장함수의 세계는 파면 팔수록 다양하다. 어떨 때는 '이런 것까지 있다고?' 싶다. 특히 알고리즘 문제를 풀 때 이런 생각을 많이 하는데, 이번 프리코스를 통해서도 다양한 내장함수를 써보았다.

 

그중 이번 미션에서는 replace()라는 내장함수를 썼는데, 이 메서드는 문자열 내의 특정 부분을 새로운 문자열로 대체하는 데에 사용된다. (참고: MDN) 두 개의 인자를 받는데 하나는 대체될 대상, 또 하나는 대체할 대상이다. 필자는 이번 미션에서 replace()를 아래 예시처럼 OutputView 클래스에 사용했다.

 

import { EVENT, OUTPUT, SPECIAL_CHARACTERS } from '../common/constants.js';
import { printMessage } from '../common/utils.js';

class OutputView {
  
  static printPreview(date) {
    printMessage(OUTPUT.preview.replace('$date', date));
  }

  static printOrder(menuList) {
    const formattedMenuList = menuList.map(menu => `${menu.getName()} ${menu.getCount()}${EVENT.count}`).join('\n');
    printMessage(OUTPUT.order_menu.replace('$menuList', formattedMenuList));
  }

  // ... 생략

export default OutputView;

 

흥미롭게도 아래와 같이 정규 표현식을 사용해 특정 단어를 모두 다른 단어로 바꿀 수도 있다.

 

const text = "Apples are round, and apples are juicy.";
text = text.replace(/apples/gi, "oranges");
// "Oranges are round, and oranges are juicy.

 

 

🧹 리팩토링

1️⃣ 필드 수 줄이기

지난 3주 차 피드백에서 "필드 수를 줄이기 위해 노력하라"라는 내용이 있었던 만큼, 이번 미션에서 필드 수를 최소화하고자 노력했다. 더불어, 피드백에 첨부된 아티클을 참고해 getter를 남발하지 않고 꼭 필요한 곳에 쓰고자 했다. (참고: getter를 사용하는 대신 객체에 메시지를 보내자)

 

3주 차 피드백 중 일부

 

예를 들어, 처음에 Discount.js라는 도메인 모델과 핵심 로직을 구현할 때는 상단에 각 할인 유형을 별도의 필드로 관리했다. 주말 할인, 평일 할인, 특별 할인, 크리스마스 할인들을 각각의 필드로 나열하고, 그 필드를 getter를 활용해 각각 꺼내오다 보니 불필요하게 코드가 길어졌고 중복된 코드가 많아진 느낌이었다.

 

그래서 각각의 할인을 하나의 필드로 묶는 게 어떨까 생각했다. 아래와 같이 각 할인 유형에 대한 값을 속성으로 가지는 '#discounts'라는 객체를 만들어, 모든 할인 유형을 하나의 객체에서 관리했다.

 

  constructor(date, orderDetails) {
    this.#date = date; 
    this.#orderDetails = orderDetails;
    this.#discounts = {
      special: 0,
      weekend: 0,
      weekday: 0,
      christmas: 0,
    };
  }

 

이렇게 묶고 나니, 아래에서 보이듯 코드 라인이 약 20줄가량 줄었고 불필요한 필드와 getter를 남발하지 않게 되었다. 필드 수가 많으면 객체의 복잡도를 높이고 버그 발생의 가능성을 높인다는 말을 실감했다. 리팩토링을 하고 나니 할인 객체를 관리하기가 훨씬 편해서 스스로 코딩하기에도 덜 어지러웠다.

 

Discount.js 리팩토링 전/후

 

2️⃣ 테스트 코드 리팩토링

지난 3주 차에 아쉬웠던 부분으로 '테스트 코드 리팩토링에 신경 쓰지 못했던 것'을 꼽았기에 이번 4주 차는 테스트 코드에서 중복되는 부분을 최대한 줄이고자 했다.

 

그중 특정 금액 구간에서 배지가 잘 부여되는지를 검증하는 Badge 클래스 테스트를 리팩토링했다. 처음에는 각 금액을 기재해 총 네 가지 테스트 코드를 작성했다. 그런데 반복되는 부분이 있다고 생각해 이를 간소화해 보기로 했다.

 

// 리팩토링 전

import Badge from '../../src/model/Badge.js';
import { OUTPUT } from '../../src/common/constants.js';

describe('Badge', () => {

  test('5000원 이상에서 별 배지 부여', () => {
    const badgeInstance = new Badge(5000);
    expect(badgeInstance.assignBadge()).toBe('별');
  });

  test('10000원 이상에서 트리 배지 부여', () => {
    const badgeInstance = new Badge(10000);
    expect(badgeInstance.assignBadge()).toBe('트리');
  });

  test('20000원 이상에서 산타 배지 부여', () => {
    const badgeInstance = new Badge(20000);
    expect(badgeInstance.assignBadge()).toBe('산타');
  });

  test('5000원 미만이면 배지 없음', () => {
    const badgeInstance = new Badge(4999);
    expect(badgeInstance.assignBadge()).toBe(OUTPUT.none);
  });
});

 

아래와 같이 'test.each' 구문을 사용해 테스트 케이스를 '일반화'했다. BADGES 배열은 테스트할 데이터(배지 이름과 금액 구간)를 포함하고, 이 데이터를 테스트에 사용한 것이다. 덕분에 세 가지 테스트 코드를 하나로 줄일 수 있었다.

 

// 리팩토링 후

import Badge from '../../src/model/Badge.js';
import { BADGES, OUTPUT } from '../../src/common/constants.js';

describe('Badge 테스트', () => {
  test.each(BADGES)('총혜택 금액 최소 %d원 이상이면 %s 배지 부여', ({ badge, amount }) => {
    const badgeInstance = new Badge(amount);
    expect(badgeInstance.assignBadge()).toBe(badge);
  });

  test('총혜택 금액 5000원 미만이면 배지 없음', () => {
    const badgeInstance = new Badge(4999);
    expect(badgeInstance.assignBadge()).toBe(OUTPUT.none);
  });
});

 

테스트 코드는 하나지만, 결과는 아래와 같이 세 개로 잘 나온다. 테스트 결과 화면에 특정 금액이 표시되지 않아서 아쉽지만..

 

Badge 클래스 테스트 결과 화면

 

3️⃣ 컨트롤러의 부담 덜기

지난 미션과 마찬가지로, 이번에도 MVC 패턴에 Layered Architecture을 적용했기에 컨트롤러의 역할 부담을 덜기 위해 서비스 레이어를 추가했다. 이번 리팩토링에서도 컨트롤러에는 비즈니스 로직을 모두 제외하고 입출력과 중개만 담당하도록 초점을 맞추었다.

 

class EventPlanner {
  
  /**
   * 이벤트 처리 및 계산된 결과 출력
   * @returns {Promise<void>} - 처리 결과를 출력하는 Promise
   */
  async manageEvent() {
    const eventProcessor = await this.#initEventProcessor(); // 사용자 input 받고 준비
  
    if (eventProcessor) {
      // EventPlanner가 직접 계산하지 않고, 계산 (비즈니스 로직)은 service layer의 EventProcessor에 위임
      // 그 결과 값만 사용
      const eventProcessingResult = eventProcessor.process(); 

      // 계산된 결과 출력
      this.#printResult(eventProcessingResult); 
    } 
  }
  // ... 생략
}

 

위와 같이 컨트롤러 역할인 EventPlanner 클래스 상단에 manageEvent 함수를 두어 사용자 입력을 받으면, 컨트롤러가 직접 계산하지 않고 서비스 레이어인 EventProcessor에 위임하도록 했다. 서비스 레이어가 연산을 완료하면, 컨트롤러는 그 값만 사용해 출력하면 된다.

 

위와 같이 컨트롤러 상단에 역할을 정의하니 가독성도 좋아지고, 컨트롤러의 부담도 덜을 수 있었다.

 

4️⃣ JSDoc 사용해 보기

JSDoc이란, 자바스크립트 소스 코드 파일들에 주석을 달기 위해 사용하는 마크업 언어다. JSDoc을 포함하는 주석에는 작성한 코드의 API를 설명하는 설명 문서를 추가할 수 있다. (참고: 위키백과) JSDoc에 대해서는 이번 프리코스를 하면서 알게 되었다.

 

지난 미션들에서 코드리뷰를 하면서 간혹 JSDoc을 사용하는 지원자들이 보였다. 아무래도 아직은 다른 사람들의 코드를 보는 게 익숙하지 않아 JSDoc의 도움을 받았기에 나도 사용해 보기로 했다.

 

이번 미션에서 핵심 파일이라고도 할 수 있는 서비스 레이어 (EventProcessor), 컨트롤러 (EventPlanner)에 아래와 같이 사용했다. 함수가 어떤 기능을 하는지, 어떤 매개변수를 전달하는지, 그리고 어떤 타입의 어떤 값이 리턴되는지 설명했다.

 

  /**
   * 총 할인되지 않은 금액과 혜택 대상 여부를 기반으로 한 가격 계산
   * @param {number} totalAmountBeforeDiscount - 할인되지 않은 총 금액
   * @param {boolean} isEligibleForBenefit - 혜택 대상 자격 여부
   * @returns {Object} - 가격 정보
   */
  #calculatePricing(totalAmountBeforeDiscount, isEligibleForBenefit) {
    const pricing = {
      totalAmountBeforeDiscount,
      totalBenefit: EVENT.zero,
      finalPayAmount: totalAmountBeforeDiscount,
    };
  
    if (isEligibleForBenefit) {
      pricing.totalBenefit = this.#calculateTotalBenefit();
      pricing.finalPayAmount = this.#calculateTotalPayAfterDiscount();
    }
  
    return pricing;
  }

 

JSDoc을 사용하면 아래와 같이 VSCode에서 자동으로 API문서를 생성해 사용하는 함수에 대한 정보를 보여주므로, 매개변수를 어떻게 부여해야 하는지, 리턴 값의 타입은 어떤지 기억이 안 난다면 코드 위에 마우스 커서를 올리면 된다.

 

함수에 대한 정보

 

여러 사람들에게 코드리뷰를 받거나, 협업을 할 때는 앞으로 JSDoc을 사용해야겠다는 생각이 들었다. 물론 작업하는 나에게도 도움이 되기도 하니까.

 

 

🤔 4주 차 아쉬운 점

1️⃣ 확장성을 더 고려할걸

미션 제출을 하고 나서야 요구사항 상단에 이벤트 목표로 '내년 1월 새해 이벤트'가 언급된 이유가 확장성을 고려하라는 것이 아닐까.. 생각했다. 예를 들어 크리스마스 디데이 할인은 날짜별로 다르게 할인이 적용되는데, constants 파일에서 날짜를 하나하나 써두었던 것, 평일과 주말도 날짜를 써두는 형식으로 코드를 짰던 게 마음에 걸린다.

 

물론 다음에는 이벤트 형식이 바뀔 수도 있고, 확장성을 고려하다 추상화를 과하게 하면 또 안 좋긴 하지만, 이 부분은 조금 더 신경 썼더라면 좋지 않았을까. 최종 코딩테스트 때는 다르게 해 봐야겠다.

 

2️⃣ 진작 일찍 잘걸

4주 차의 아쉬움이라기보다, 지난 3주간의 컨디션 조절을 잘 못했던 것이 아쉽다. 3주 동안은 새벽 4-5시쯤 늦게 자거나 밤을 새고, 다음날 점심때가 다 되어서야 일어났는데 이렇게 되니 잠을 자도 잔 것 같지 않고, 오후 내내 집중력이 흐트러졌다. 무엇보다 늦게 일어나니 '기상의 뿌듯함'이 없었다.

 

불안해서 새벽까지 붙들고 있다 보면 뭔가 하고 있기는 한데, 사실 불안한 마음이 커서 큰 소득이 없었다. 어차피 점심때쯤 일어나는 거면 수면시간은 똑같기에 조삼모사 같았다. 사람마다 다르겠지만 나는 확실히 일찍 자고 일찍 일어나는 게 맞는 것 같았다. 그래서 4주 차부터는 과감하게 생활 패턴을 바꿨다.

 

4주 차부터는 제출 직전 날을 제외하고는 새벽 2시면 무조건 자고, 다음날 아침 7시에는 일어났다. 그랬더니 '기상의 뿌듯함'을 느끼면서 아침에 환기 겸 창문을 열면 기분이 좋아졌다. 커피를 내리고, 아침밥을 먹으며 코딩하니 행복하기까지 했다. 역시 몸은 정신을 지배한다는 것을 느꼈다. 컨디션 조절도 하나의 역량이라고도 생각했다.

 

 

☕️ 4주 차 소감

1️⃣  4주 차 미션을 받고

4주 차 미션을 처음 접했을 때는 요구사항의 길이로 압도당했지만, 실제 개발자로 일하며 업무를 배정받았다는 생각을 가지고 임하니 재미있었다. 앞으로는 문제의 내용이 많으면 압도당하기보다, 오히려 친절한 설명이라는 생각에 감사하고 침착할 수 있을 것 같다.

 

2️⃣  4주 차 미션 수행 과정

마지막 미션인 만큼 지난 3주간 배운 것들을 모두 녹여내고자 했다. 이를 위해 지난 1주 차부터 3주 차까지의 모든 피드백과 교육 자료를 총 복습했고, 학습 내용을 미션의 요구사항에 적용하며 설계에 공을 많이 들였다. 예를 들어, 메뉴 / 주문 / 배지 등 각 객체들이 가지는 역할을 분리하여 필요한 메서드들을 미리 고민하고 적어두었다.

 

앞서 이야기한 것처럼 지난 미션들에서 적용해 보았던 MVC 패턴과 Layered Architecture은 이번 프로젝트에도 적용하며 컨트롤러의 역할이 너무 커지지 않도록 서비스 레이어를 추가했다. 컨트롤러는 입출력과 같은 사용자 인터페이스 로직만을 담당하고, 비즈니스 로직은 서비스 레이어가 담당할 수 있게 했다.

 

더 작게 파고들자면, 함수 라인의 제한이 있었던 덕분에 메서드들이 하나의 역할만을 할 수 있도록 고민했고, 이는 나에게 매우 유의미한 경험이었다. 또한 코드리뷰를 하며 JSDoc 덕분에 코드를 이해하기 더 편했던 기억이 있어, Controller와 Service Layer에 문서화를 하기도 했다. 이로써 객체 지향적인 사고를 비롯해, 아키텍처와 디자인 패턴의 중요성, 그리고 보기 좋은 코드의 중요성을 스스로 체감하며 적용할 수 있었다.

 

또한 커뮤니티 안에서 지원자들과 이야기 나누며 스스로 공부할 주제를 만들어 나가기도 했다. 예를 들어 클린한 소스코드와 테스트 코드를 쓰기 위해서는 어떤 점에 신경 써야 하는지에 대한 시야를 넓혀나갈 수 있었다. 덕분에 지금까지 받은 소중한 코드리뷰들을 모아 체크리스트를 만들어, 코드를 짜며 잘 지키고 있는지 점검하기도 했다.

 

다만, 설계나 리팩토링 측면에서는 아직 시야가 좁다고 생각하기에 프리코스 기간 동안 겉핥기 수준으로 공부했던 것들을 차차 학습해 나갈 계획이다. 프리코스 기간 동안 매주 성취감을 느끼기도 했지만, 공통 피드백이나 코드리뷰를 통해 매주 아쉬움을 남기기도 했다. 하지만 이 아쉬움을 느낄 수 있음에 감사하기도 했다. 이로써 피드백은 성장의 큰 자산이라는 것을 다시 한번 체감할 수 있었고, 프리코스가 끝난 이후에도 지원자들과의 인연을 유지하며 피드백을 주고받고자 한다.

 

3️⃣ 잘 해낼 수 있는 환경 만들기

지난 3주 차 미션 이후, 멘탈 관리를 잘해야겠다는 생각이 크게 들었다. 미션을 하던 당시에는 하루하루 풀리지 않는 문제에 힘이 들었다. 하지만 이는 미션이 나를 힘들게 하는 것이 아니라, 나를 둘러싼 것들이 힘들게 만드는 것이었다.

 

3주 차 때 컨디션 조절을 잘하지 못해 힘든 상황 속에서 미션을 수행하다 보니 몸도 마음도 지쳤다. 하지만 4주 차부터는 집중이 되지 않을 때는 디스코드 모각코 방에서 지원자들과 함께 이겨내고, 최소한의 수면 시간을 확보해 다음날 컨디션에 무리가 없도록 했다. 생활 패턴을 단숨에 바꾸는 것은 어려운 일이라 생각했지만 절실한 마음 덕분이었는지 무리 없이 잠에서 깰 수 있었다. 이처럼 스스로가 ‘잘 해낼 수 있는 환경’을 만들며 성장하는 개발자가 되고자 한다.