[TIL]🍔햄버거 키오스크 프로젝트 회고

📢 1. 프로젝트 소개

✔️ 패스트푸드 가게를 방문하는 고객을 위한 주문 키오스크 프로그램

• github : https://github.com/YejinY00n/CalculatorProject
  
  
  

주요 기능

🍔 메뉴 출력

목적: 사용자가 카테고리 별로 메뉴를 선택할 수 있다.

• 카테고리별 메뉴 분류: 햄버거, 음료, 사이드 메뉴 등으로 카테고리별로 메뉴를 출력
• 세부 메뉴 출력: 각 카테고리 안에서 사용자가 선택할 수 있도록 메뉴를 나열
  
  

🛒 장바구니

목적: 사용자가 메뉴를 장바구니에 담고 수정할 수 있다.

• 메뉴 담기: 사용자가 원하는 메뉴를 장바구니에 담을 수 있음
• 장바구니 수정: 메뉴명을 입력하여 장바구니에서 메뉴 삭제
• 장바구니 비우기: 장바구니를 초기화하여 주문을 취소
  
  

💳 주문

목적: 사용자가 장바구니에 담긴 메뉴를 확인하고 결제한다.

• 총 금액 계산: 장바구니에 담긴 메뉴의 총 금액 계산
• 할인 적용: 할인 유형에 맞춰 금액을 할인을 적용
• 결제 완료: 최종 결제 금액을 출력하고 장바구니를 초기화

실행 화면

🍔메인 화면

---

🛒장바구니 화면

---

🧾주문 화면

🛠️ 2. 트러블 슈팅

Git 관련

📌 커밋 메세지 수정

⛔ 문제

commit e1fdbd15dda7cb5f3fdf19116c8a79004ae84db2 (HEAD -> dev)
Author: YejinY00n <yoon17710@gmail.com>
Date:   Fri Mar 7 20:49:37 2025 +0900

    Refactor: Lv3. Kiosk 클ë<U+009E>클래스ì<U+0097> 클래스로 제어 담당 이전

commit 4edb0fa8b2e78bb54b72f9f96555a1a6df923319 (main)
Author: YejinY00n <yoon17710@gmail.com>
Date:   Fri Mar 7 20:06:50 2025 +0900

    Feat: Lv.1 기본 키오스크 기능 ì(메뉴 ì (메ë<U+0089>추가 - ¶<U+009C>ë  출력
:

• git bash 커널을 통해 커밋 후 로그 내역 확인해보니 위와 같이 커밋 메세지 글자가 깨져있음

---

❓ 원인

• git bash의 인코딩 문제로 한글이 제대로 메세지에 저장되지 않음

---

❗ 해결

커밋 내역이 아직 로컬에만 존재한다면 아래와 같은 해결 방법을 사용할 수 있다.

git log

커밋 내역을 확인하여 수정해야하는 메세지의 위치를 파악

1) 가장 최근의 커밋 메세지

git commit --amend

가장 최근의 커밋 메세지 하나를 수정할 수 있다.

2) 가장 위에서부터 N번째 메세지 수정

git rebase -i HEAD~N

명령어 사용 시 현재 작업 브랜치의 가장 최근 커밋 N개를 보여준다. 여러 개를 수정해야하거나 가장 최근이 아닌 커밋 메세지를 수정해야할 때 사용할 수 있다.

사진과 같이 커밋 내역을 확인할 수 있다. 이 중 수정하려는 커밋의 pick을 reword로 변경한 후 저장하면, 해당 커밋을 수정할 수 있는 창이 열린다.

추가) vim 문법

커밋 메시지를 수정할 때 vim이 기본 편집기로 사용되므로, 다음과 같은 기본적인 명령어를 익혀두면 좋다.

i : 기본 모드에서 insert 모드로 전환하여 파일 내용을 수정할 수 있다. 하단에 -- INSERT --가 표시되면 입력 모드에 진입한 것이다.
Esc : 명령 모드로 돌아가며, 추가적인 명령을 입력할 수 있다. 하단에 :가 표시되면 명령모드에 진입한 것이다.
:wq : 변경 사항을 저장하고 vim을 종료하는 명령어.
:q! : 변경 사항을 저장하지 않고 강제로 vim을 종료하는 명령어.

• 혹은 Windows Powershell을 통해 git을 사용하면 인코딩 문제로 인한 메세지 오류 발생 확률이 낮아짐.

입출력 처리

📌 Scanner nextInt() 사용 후 nextLine() 사용 문제

⛔ 문제

• 사용자 입력 받기 후 특정 로직 진입 시, while 문이 무한 루프하는 문제 발생
• 예시: 입력값이 0이 아니면 계속 반복하도록 설정했을 때 문제 발생

  ---

❓ 원인

• nextLine()으로 입력받을 시 정수만 읽고 개행 문자(\n) 이전까지만 처리
• 마지막 개행 문자가 제거되지 않고 버퍼에 계속 남아있음
• Scanner를 다시 호출 시 버퍼의 개행 문자가 입력되어 처리되어 문제 발생

---

❗ 해결

✅방법 1) sc.nextLine() 으로 개행문자 제거

sc.nextInt();			// nextInt 호출 후
sc.nextLine();        // nextLine으로 개행 문자 제거

✅방법 2) Integer.parseInt() 사용

Integer.parseInt(sc.nextLine());		// 문자열로 읽은 후 Integer 변환

코드 가독성이 더 높은 방법2를 사용하여 입력 부분 문제 처리함.

예외 처리

📌 적절하지 않은 예외 타입 사용

⛔ 문제

• 기능 테스트 중 사용자 입력 받는 부분에서 try-catch로 예외 처리를 하도록 설계하였으나 의도대로 동작하지 않음.

• nextInt()로 사용자의 메뉴 선택을 받는 부분에서 문자열을 입력 받으면 예외가 발생해야 하지만, IllegalArgumentException을 catch하는 방식으로는 처리되지 않았음.

---

❓ 원인

• 사용자 입력에서 적절하지 않은 예외 타입 IllegalArgumentException를 catch하는 것으로 처리함

---

❗ 해결

IllegalArgumentException 대신 InputMismatchException을 사용하여 예외 처리하도록 변경 후, 입력값이 올바르지 않을 때 정상적으로 예외가 처리되도록 수정함.

• IllegalArgumentException : 메소드에 전달된 파라미터가 요구된 자료형이 아니거나 범위를 벗어날 때 발생한다. 메소드의 파라미터 유효성을 검사할 때 주로 사용.

• InputMismatchException : 스캐너로 값 입력받을 때 다른 종류의 자료형을 입력 시 발생한다. 입력 부분 예외 처리를 다룰 때 주로 사용.

🕵️‍♀️ 3. 고민한 부분 / 어려웠던 부분

예외 처리

🔍 구체적인 예외 타입 사용

• 기존의 포괄적인 타입인 Exception을 사용하여 예외 처리를 하는 방식 대신 구체적인 예외 타입을 사용
  
  
  

🔍 try-catch 범위 줄이기

기존의 try-catch 범위가 넓어 범위를 줄였음.

• 기존 방식은 에러 로그 추적 및 테스트 시 어느 지점에서 발생했는지 추적하기 어려움
  
  

반복적인 예외 처리의 경우(ex. 사용자 입력) 불필요하게 중복된 코드가 존재함.

• 해당 기능(사용자 입력) 혹은 예외 처리 로직 자체를 메소드로 분리하여 코드 재사용성을 높이는 방향을 고민 중.

---

리팩토링

🔍 기본 과제 Lv.3 ➡️ Lv.4

Menu 클래스를 생성하여 MenuItem 관리를 Kiosk 클래스➡️Menu 클래스로 이동

🚧 기존

• MenuItem 리스트를 카테고리마다 생성해야함
  • List<MenuItem> burgerList, List<MenuItem> drinkList, List<MenuItem> sideMenuList 등 하드코딩 필요
  • 새로운 카테고리를 추가할 때마다 리스트를 추가해야 하므로 확장성이 낮음
    
    
• Kiosk 클래스의 책임이 많아서 역할이 불분명했음 (ex. 메뉴 출력, 흐름 제어...)
  • 단일 책임 원칙을 위반하여 가독성 및 유지보수가 떨어짐
    
    

🔄 리팩토링 후

• Menu 클래스를 생성하여 MenuItem 관리 담당
  • 공통 기능을 Menu 클래스에서 관리할 수 있음
    
    
• Kiosk 클래스의 역할이 보다 명확해짐
  • 키오스크 운영 및 흐름 제어 위주의 로직으로만 구성됨

---

🔍 장바구니 클래스 관리

가장 고민한 부분
장바구니 ShoppingCart 클래스를 어디에서 관리할 것인가?

• Kiosk에서 그대로 관리하는 것으로 유지할지?
• OrderService를 만들어 주문 관련 로직을 분리할지?
  
  

✅ 1안: Kiosk 클래스에서 관리
✔️ 구현이 단순함
✔️ Kiosk가 모든 흐름을 제어하므로 데이터 주고받기가 직관적임
❌ 확장성이 떨어지며 Kiosk 클래스의 역할이 불필요하게 확장됨

✅ 2안: OrderService를 생성하여 주문 관련 도메인 관리
✔️ Kiosk가 흐름 제어 및 사용자 입력만 담당하고, 주문 로직은 OrderService에서 관리하여 명확한 책임 분리
❌ 데이터 흐름을 설계하는 과정이 복잡하여 구현 난이도 상승
❌ Kiosk와 OrderService 간의 데이터 전달 방식을 잘 설계해야 함.
(ex. 장바구니에 메뉴 추가 시 Kiosk와 OrderService가 어떻게 통신할지?)

• 1안 방식보다 흐름 제어, 데이터 주고받기(ex. 장바구니에 메뉴 추가 부분)의 구현 부분에서 어려움을 느낌.
  
  

💭 2안에서 고민한 부분

• 기존 1안이 단순하지만 Kiosk가 너무 커지는 문제가 있어 분리 필요성을 느낌
• 하지만 OrderService로 분리하는 과정에서 흐름 제어 및 데이터 전달이 어려움
• Kiosk 클래스의 기능을 어디까지 분리할지?
• 그에 따라 Enum Discount, Menu 등의 클래스를 Kiosk와 OrderService 중 어느 곳에서 관리하게 할지?
  
  

잠정적 결론 : 현재는 1안으로 main 브랜치에 배포하였으나 추후 리팩토링 과정에서 2안을 도입할 예정.

🔍 기존의 코드를 메소드로 분리

Kiosk클래스의 start() 함수가 너무 길어져 코드 가독성이 떨어지는 문제 발생

✅ 따라서 일부 로직을 메소드로 분리

✔️ 코드가 구조적으로 더 깔끔해지며 유지보수가 용이
❌ 메소드 분리했음에도 오히려 코드가 더 복잡해 보이는 경우가 있음

💭 메소드 역할이 명확하지 않거나 메소드 이름이 직관적이지 않을 가능성
💭 start() 함수 하나에서 여러 함수를 호출하여 데이터 전달 증가 및 메소드 간 의존성이 높아져 코드가 더 복잡해졌을 가능성
💭 메소드 분리 단위가 너무 잘게 쪼개졌을 가능성

잠정적 결론 : 메소드 분리 기준을 더 명확히 정의할 필요성이 있음
ex) 함수의 역할, 데이터 흐름, 함수 네이밍, 메소드 분리 단위...

마무리

도전과제까지 구현 마무리 후 리팩토링을 하려고 코드를 다시 살펴봤는데 정말 구현만 끝냈다는 생각이 들었다. 실행은 되긴 하는데..

아무튼 실행은 되죠?

하지만 코드를 열어보면 고민했던 부분에서 적어둔 것처럼

• 가독성
• 하드 코딩된 부분(확장성, 유연성)
• 하나의 클래스(특히 키오스크)에서 관리하는 객체와 담당하는 책임(기능)이 많음

같은 문제점이 보였다.

나는 코딩할 때 가독성 있게, 클래스를 구조적으로 작성하는 것을 가장 중요하게 생각한다.

나름 이 부분을 신경쓰면서 코드를 작성하려고 했으나 클래스를 추가하면서 코드가 점점 꼬인 것 같다.
또 요구사항을 다르게 해석한 것이 있어 완성본까지 코드 짜는 데 반, 리팩토링에 절반의 시간을 쓴 것 같다. 완전 날림 공사했다 😗

다음 프로젝트에서는 시작 전에 다이어그램을 직접 그려보면서 프로그램의 구조를 파악하고 코드 작성을 시작하도록 해야겠다.

참고

https://velog.io/@mayinjanuary/git-%EC%BB%A4%EB%B0%8B-%EB%A9%94%EC%84%B8%EC%A7%80-%EC%88%98%EC%A0%95%ED%95%98%EA%B8%B0-changing-commit-message
https://0soo.tistory.com/103