Hotel_SemiProject: A Java repository from Kang-Hyesung

호텔 체크인 키오스크

기획의도 기존 호텔 체크인 키오스크에서 이용자가 사용할 수 있는 기능이 한정되어 있다 생각하였고 이 점을 보완하여 다음과 같은 기능을 가진 키오스크를 구현하고자 하였다
1. 간편 체크인
  - 데스크에서 웨이팅/직원의 도움 없이 고객이 직접 빠르고 간편하게 체크인 가능
2. 무인 객실 구매
  - 기존 체크인 키오스크에서 예약자만 이용 가능한 점을 보완하여 현장에서도 객실 구매 가능
3. 어메니티 및 식사 구매
  - 키오스크에 자판기 기능을 결합하여 시간과 장소에 구애 받지 않고 원하는 제품과 서비스 구매 가능
프로그램 구성
1. 예약 X -> 회원 X -> 개인정보 입력 후 객실 선택 -> 어매니티 및 식사 구매 -> 장바구니 -> 결제 및 정보 출력
2. 예약 X -> 회원O -> 개인정보 입력 생략(회원정보에 있으므로) -> 어매니티 및 식사 구매 -> 장바구니 -> 결제 및 정보 출력
3. 예약 시스템 모드(인터넷에서 예약하는 기능이라고 가정) 회원인지 물어본 후 객실 구매 -> 결제 및 정보 출력(어매니티는 체크인 하면서 구매 / 자판기이므로)
4. 관리자 모드
  1. 남녀, 연령, 객실 타입별 이용 현황(통계) 확인 가능
  2. 객실 총 매출, 남녀, 연령, 객실 타입별 매출 확인 가능
  3. 호텔 재고 관리(면도기, 샤워타올, 칫솔치약 등)
코드 구현
1. Room 클래스에서는 예약이냐 당일이냐에 따라 체크인 날짜(시작 날짜)가 달라지기 때문에 구별함
2. 인터페이스는 인터페이스의 적절한 예시가 아닌 것 같지만 비슷한 내용을 수행하는 두 클래스를 묶어주기 위해 사용함
3. 직렬화 / 역직렬화 하는 것들은 저장되어야 할 것들. 예약 번호로 필요한 모든 정보에 접근이 가능하도록 함. 이제 실제 구현한 코드를 간단하게 볼 것
4. flag -> 1일 ~ 2일의 101호 객체가 있고 3일 ~ 4일의 101호 객체가 있을 때 방 번호만으로 구분하면 겹치는 경우가 생김 -> 그걸 해결하기 위해 boolean 자료형의 변수를 활용
5. while문을 돌면서 기존에 있던 101호 객체의 시작 ~ 종료 날짜의 범위가 오늘과 겹치는게 하나라도 있다면 체운 네모 출력 , flag를 true로 변경 boolean 배열은 사용자가 이용중인 방을 선택했을 때 입력하지 못하게 하려고 만든 배열임(코드의 중복을 피하기 위함) while문 앞에 flag는 다시 false로 세팅
6. 밑에서 flag가 false라면 기존에 있던 객체의 시작 ~ 종료 날짜의 범위가 오늘과 겹치는게 없다라는 뜻이기 때문에 빈 네모 출력
추가사항 직렬화 / 역직렬화 목록
1. <Hashtable <String, room> roomMap> 예약 번호 / 객실 객체
2. int[] stockArray 호텔 재고 보유랑을 저장하는 int형 배열
3. Hashtable<String, Reserve> Guest 예약번호 / 예약자 객체
4. Hashtable<String, int[]> cusArray 예약번호 / 고객이 구매하는 어매니티 정보를 담는 int형 배열
발표 자료 https://drive.google.com/drive/u/0/folders/1L0VkWSJpj31TroSwKpXhbesBV-cFZBs_

후기

나는 이번 프로젝트에서 팀장을 맡게 되었다. 학원에서의 팀장은 학교에서와는 다르게 훨신 더 주도적으로 이끌어 나가야 하는 자리였다. 나는 리더역할에는 자신이 없었지만 최대한 잘 이끌어 나가려고 했고 팀원들도 잘 따라주었다. 겉으로 티는 내지 않았지만 팀원들은 막히는 것이 있으면 나에게 물어볼 수 있었지만 내가 막히는 것은 어떻게 해결해야 되는지 참 난감했던 적이 있었다. 다행히 우리와 비슷하지만 다른 주제를 가진 다른 팀의 팀장과 소통하며 잘 해낼 수 있었던 것 같다. 팀원들에게 해야할 일들을 나누어 줄 때는 모두가 어려운 것을 최소한 하나씩은 구현해보면서 다같이 실력을 키워보자 라는 생각으로 접근했다. 나는 구체적으로 설명을 해주고 나누어 주었다고 생각했으나, 내 의도와는 다른 식의 결과물이 나올 때도 있어서 소통의 중요성을 깨닫게 됐다. 나는 개인적으로 첫 프로젝트를 진행하면서 실력이 느는걸 느꼈고 이번에 경험한 것들은 앞으로 오랫동안 기억할 것 같다.

1. 초반 설계는 중요하다

우리조는 다른 팀들에 비해 클래스 다이아그램이나 순서도 등을 엄청 세부적으로 짜놓지는 않았었는데 그 이유는 어차피 진행하면서 많이 바뀔 것이라 생각했고 그 과정에서 시행착오를 겪으면서 여러 경험들을 해봤으면 하는 생각이었다. 하지만 위에서 말한 것처럼 우리가 세부적으로 정하지 않은 것들(변수,메소드,클래스 작성방식)을 내가 구두로 설명해주고 일을 맡기다 보니 팀장 입장에서는 팀원들 모두가 하는 일이 내 머리속에 구체적으로 있었어야 했고 그들이 다른 방향으로 나갈 때마다 다가가서 방향을 잡아줘야 했고 팀원들 입장에서는 설명을 들을 때는 알겠는데 막상 작성해보려 하니까 어떻게 해야할지 혼란스러워 하는 느낌이 있었다. 다음에 프로젝트를 진행한다면 초반 설계를 조금 더 꼼꼼하게 하고 일을 나눌 것이다.

2. 버전 관리의 필요성

우리는 git을 이용하고 싶었으나 나 포함 능숙하게 할 줄 아는 사람들이 없었고 구글 드라이브에 각자 작업한 코드들을 올리는 식으로 진행했다. 내가 그것들을 모아 전체 파일들을 github에 올렸고 팀원들은 그것을 복사해서 진행했는데 다음 프로젝트를 할 때는 git으로 협업하는 걸 경험해 보고 싶다. 나는 지금부터 수업 복습 이외에 따로 git을 조금씩이라도 공부할 생각이다.

3. 메소드 혹은 클래스는 나누는 것이 좋다

초반에 작업하면서 실행 결과를 확인하면서 하다보니 하나의 메소드에서 이 기능도 하고 저 기능도 하는 그런 상황이 있었는데 그렇게 하다보니 A 메소드에서 오류가 생기면 A 메소드로 들어가 진행을 해야 되는데 AA라는 메소드에 A기능, B기능, C기능이 있다보니 내가 원하는 곳으로 돌려주는 것이 어렵다는 생각을 했고 그 때부터 메소드들을 나누어 주면서 예외처리나 돌아가야 하는 부분들을 잡아주었다.

4. static을 잘 활용하자

우리 조는 static을 거의 쓰지 않았는데 이는 우리가 초반에 설계를 꼼꼼히 하지 않은 점 때문이기도 하지만 내 의도는 각자가 클래스 생성자나 메소드의 매개변수를 잘 활용하면 굳이 쓸 필요가 없다라는 생각이 있었다. 물론 이번 프로젝트는 연습의 성격에 가깝다고 해서 그 후회는 있지 않지만 static으로 필요한 것들을 활용했다면 훨씬 더 수월하게 진행을 했을 것이기 때문에 다음 프로젝트 때는 static을 조금 더 적극적으로 활용할 계획이다.

5. 업무 분배를 잘하자

아무래도 팀원 각자의 실력이 있기 때문에 좀 후반부에 합치는 과정을 진핼할 때는 입출력 텍스트들을 수정하는 것 이외에는 팀원들이 할 일이 그렇게 많지는 않았다. 나중에 들은 얘기지만 합치는 과정에서 어떤 부분에서 오류가 있는지 할 일이 어느정도 마무리된 팀원에게 테스트를 부탁했는데 그 팀원이 말하길 본인이 실력이 부족해서 많이 도와주지 못한 부분이 있어서 미안하게 생각하고 있었는데 내가 일거리를 맡겨주어서 굉장히 고마웠다고 했다. 그때 나는 내가 업무분배를 조금 더 신경써서 잘했으면 그런 감정이 들 일이 없었을 것 같아서 그런 감정을 느꼈다는 것 자체가 좀 미안했다.

6. 오류 잡는 기간은 생각보다 길다

5번에서 말했듯 합치는 과정에서 생기는 오류들을 모아달라고 팀원에게 부탁했었는데 문제가 되는 부분이 메모장 한 가득이었고 그것을 봤을 때 너무 막막했다. 어찌어찌 하나씩 수정하긴 했지만 시간이 꽤나 걸렸다. 프로그램을 구현하는 기간에서 코드 작성기간만 생각했는데 오류 잡는 기간도 생각해서 계획해야 할 것 같다.

7. 디버깅의 중요성

마지막에 오류 잡는 과정에서 여러 클래스가 뭉쳐있고 복잡한 구조여서 어디에서 문제가 생기는지 도저히 알 수가 없었는데 그때 인텔리제이의 디버그 모드를 적극적으로 활용했다. 나는 디버깅 없이는 완성하지 못했다고 말 할 수 있을만큼 도움을 굉장히 많이 받았다. 이번 프로젝틀를 진행하면서 많이 고생했지만 디버깅이라는 것에 조금 더 익숙해져서 이 부분은 굉장히 만족하는 부분이다.

8. 항상 긍정적으로 생각하자

코드와 관련은 없지만 프로젝트를 진행하면서 막바지에 다다를수록 나도 모르게 예민해져 가는 걸 느꼈다. 예민해지는건 어쩔 수 없는 거지만 팀원들에게 조금 더 친절하게 말해줄 수 있는 것들을 약간 툭툭 던지는 식으로 얘기 했던게 마음에 걸린다. 내가 발표를 맡고 ppt에 후기를 간단하게 적는 페이지가 있었는데 나는 말로 할테니 ppt에서 내 후기를 빼달라고 했었는데 그 이유는 발표를 하는 사람들중에 팀장인 경우는 나 밖에 없어서 팀장의 입장에서 느낀 후기를 말해보고 싶기도 했고 마지막에 느꼈던 미안했던 부분들을 그때 얘기하고 싶어서였다. 팀원들의 반대로 그렇게 하지는 못했다. 내 성격상 발표때가 아니라면 하지 못했을 이야기라 그때 미안하다고 말하지 못한게 너무 아쉽다. 그때 얘기하고 싶었던 말을 여기에 적으면서 마무리 하고자한다.

개인적으로 각자의 실력에 최대한 근접하게 일을 배분해 주고 싶었는데 그러지 못한 것 같아서 미안하고 내가 꼼꼼하지 못하다 보니까 놓치는 것들을 잡아줘서 고맙다는 말을 하고 싶습니다. 막바지로 갈수록 나도 모르게 압박을 느끼다 보니까 예민해진 경향이 있는데 이 때문에 기분이 나쁘거나 상처받았던 팀원이 있다면 너무 미안하고 내 속마음은 그렇지 않았다는걸 알아줬으면 좋겠습니다. 저는 이번 프로젝트를 진행하면서 실력이 느는걸 느꼈는데 팀원분들도 나와 비슷한 느낌을 받았으면 좋겠고 앞으로도 지금처럼 잘 지냈으면 좋겠습니다.

끝

Kang-Hyesung/Hotel_SemiProject