프로젝트가 끝나지 않아 아직 미완성인 글
더 추가 예정

호텔 예약 시스템

1. 필수 요구 사항

• 필수 요구 사항
  1. 호텔은 여러 객실, 보유 자산을 가지고 있다.
  2. 객실은 객실 당 하루에 한 사람만 예약이 가능하다.
  3. 객실은 크기, 숙박비를 가진다.
  4. 예약은 객실, 고객의 이름, 고객의 전화번호, 예약 날짜를 가지고 있다.
      (1). 전화 번호 제한(XXX-XXXX-XXXX) 정규 표현식 (선택)
      (2). 예약 날짜
        날짜는 ISO 8601 형식으로
        조합된 UTC 날짜 및 시간
        예) 2016-10-27T17:13:40+00:00
     
  5. 고객은 이름, 전화번호, 소지금을 가진다.
      (1). 고객 소지금보다 비싼 방은 예약 불가
  6. 호텔은 모든 예약 목록을 조회 할 수 있다.
  7. 고객은 자신의 예약 목록을 조회 할 수 있다.
      (1). 예약 번호로 예약 내역을 조회한다
  8. 고객은 자신의 예약을 취소 할 수 있다.
  9. 고객이 호텔 예약 시에 예약 번호(id)를 반환 (uuid 활용)
      (1). 고객이 호텔 예약에 성공하면 예약 번호(id)를 받는다.
      (2). 고객이 예약 목록을 조회 시 예약 번호도 같이 조회 된다.
      (3). 고객이 예약 취소 시 예약 번호를 통해 자신의 특정 예약을 취소한다.

1-1 추가 작업

• 날짜를 정규식으로 입력 받았다. ex) 2022-12-25
  "\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])"
• 입력 받은 날짜가 현재 날짜를 기준으로 당일 혹은 미래여야 예약이 가능하도록 구현하였다.
• 관리자와 고객 페이지를 따로 만들어두었다.
• 객실은 객실번호(고유키), 객실 사이즈, 객실 가격을 가지고 있다.

2. 클래스 다이어그램

프로젝트의 구조적 설계를 위해 클래스 다이어그램을 만들었다.

1차 초기 다이어그램

2차 수정 다이어그램

3차 아직 다이어그램 안 만든 상태 ( 추가할 예정)

문제점

• 코딩 다 끝내고 나서야 만드는 최종 클래스 다이어그램.
  팀원들 모두 프로젝트 경험이 거의 전무하고 자바 언어의 이해가 높지 않아, 프로젝트 초기 단계에서 전반적인 구조를 짠다는 것이 매우 어려웠다. 코딩을 하면서 필요한 메서드와 변수들이 계속 생겨났다. 처음에 만들었던 1차 다이어그램은 다 틀렸다고 봐도 무방하다. 다이어그램의 목적이 무색하게 코드를 다 짜고 나서야 코드를 보며 클래스 다이어그램을 짜게 되었다.

3. GitHub

https://github.com/Team5-MiniProject/HotelProject

4. 미해결 & 부족한 부분(11월27일 기준)

1. 예외처리가 필요함에도 추가하지 못한 부분이 매우 많다.
   → 예외처리 지식이 부족했고, 거의 완성이 되고 나서야 예외처리의 필요성을 알게되었다. 리팩토링이 필요하다.
2. 3-Tier Architecture를 고려하지 않았다.
3. 메서드의 분활 기준에 대한 지식이 부족하다.
   → Hotel 클래스의 receiveBooking()이 너무 많은 역할을 한 번에 처리하고 있는 것이 아닌가 하는 의문이 있다. (28일 튜터님께 코드리뷰를 받을 예정이다)
4. 고객의 중복 예약 해결을 포기했다.
   → 필수 요구 사항에 명시가 되어있지 않았고, 추가 구현을 하기엔 벅찰 것 같아 비회원제라는 의미를 부여했다.
5. 클래스와 변수명이 다소 조잡하다.
6. 리드미 작성(월요일에 작성할 예정)

5. 잘한 점

1. Setter 사용을 지양하고 의미를 부여하기 위해 노력했다.
2. 구조의 중요성을 알고 구조적 고민에 많은 시간을 쏟았다.
3. 수정을 두려워 하지 않았다. 요구사항이 애매하다 여겨지는 부분을 계속 고민하여 기능을 추가하고, 이미 작성된 메서드를 중간 중간 리팩토링 해주었다.
4. 클래스 다이어그램을 사용했다.
5. Github을 사용해 팀 프로젝트의 효율을 높였다.
6. 커밋 단위를 쪼개고, 변동 사항을 자세히 서술했다.

6. 후기(a.k.a. 반성의 시간)

스스로에 대한 현타

사실 프로젝트 첫 날 과제였던 메모장 프로젝트를 할 때, 나는 자바를 배웠다고 말하기도 부끄러운 수준이었고 지금까지 알고 있던 이론들이 뒤죽박죽되어 어떻게 손을 대야하는지 감이 오지 않았다. 스스로에 대한 부끄러움과 실망감 그리고 하루 안에 끝내야 한다는 긴장감으로 너무 기초적인 부분조차 혼란스러웠다.

지금까지 이론 공부를 해오면서, '지금까지 해온 게 있는데, 쉽다', '할만 하네~'하며 자만했었는데 막상 프로젝트를 시작하니 자바를 처음 배우기 시작한 팀원들과 다를게 없었다. 거기서 오는 현타가 정말 컸다. 지금까지 난 뭘 해온건가? 싶은 마음이었다.

연희 튜터님께 질문을 하러 갔을 때, 너무 속이 상했다. '이런걸 질문하러 오다니..'하는 마음에 이미 주눅이 들었고 튜터님은 정답을 알려주시기보다 스스로 생각을 이끌어내도록 해주셨는데 어버버 하고 있는 내모습이 싫었다.

지금 생각해보면 저 경험을 통해 지금까지 내가 열심히 하지 않아 흘려왔던 시간들을 마주할 수 있었던 것 같다. 나는 아직 너무 부족하고 배워야할 게 산더미니까 진짜 열심히 해야한다는 걸.

우당탕탕 메모장 해결

안타까운 일이지만, 28일 새벽인 지금 내가 메모장을 어떻게 끝냈는지 기억이 안난다. 한참을 헤매고 손으로 구조를 짜 가면서 하나하나 하다보니 얼추 완성을 해버렸다.

지금 생각해보면 메모장의 선행과제를 통해서 오히려 호텔 프로젝트는 즐겁고 수월하게 해낸 것 같다. 1. 유일키의 중요성 2. 클래스간의 관계(구조) 3. 객체지향의 지식. 이 3가지를 얻어냈기 때문이다.

처음에는 '아니 왜 프로젝트 전에 이걸 해야하지?' 싶었는데 튜터님들의 선견지명(?), 깊은 생각에 감사를 드린다.

구조의 중요성 (feat. 튜터님들 멋쟁이)

호텔 프로젝트 첫 날에는 반나절동안 팀원들과 클래스 다이어그램 짜고 역할 나누느라 시간을 썼고, 남은 반나절은 깃허브 푸쉬 오류 해결하느라 날렸다. 둘쨋날에는 혼자 '구조'에 집중했다. 진짜 반나절 이상을 클래스간 관계, 객체의 생성 위치, 메서드의 위치 등 구조를 생각하는데 썼다. 메모장 한 번 해봤다고 갑자기 모든게 익숙해지진 않았다. 그래도 내가 팀원들보다 자바 공부를 좀 더 해왔기 때문에 팀원들이 쉽게 이해하고 코드를 작성하도록 틀을 짜줘야한다는 생각을 했기 때문이다.

그래서 시영 튜터님께 구조적인 코드리뷰를 받았고, 여기서 일차적으로 프로젝트에 대한 이해도가 확 올라갔다. 밤 11시에 즈음에 잠시 방문한 승민 튜터님께도 코드리뷰를 받아 'Setter를 지양해야 하는 진정한 의미'를 알았고, 추가적인 구조에 대한 지식을 얻었다.

두 튜터님으로 구조에 대한 해답을 찾고 나니까 갑자기 보이지 않던 것들이 보이기 시작하고 어떻게 해야할 지 방향성이 보이기 시작했다. 이 깨달음을 빨리 코드를 짜서 구현하고 싶어졌고 그렇게 그날 밤을 새서 코딩을 했다.

젊어서 가능한 밤샘 코딩

그러나 토요일 새벽의 밤샘 코딩은 내 큰 단점 버튼을 눌러버렸다....😓

팀 프로젝트란 걸 잊지마!!

대학시절을 돌이켜보면, 팀 프로젝트가 있을 때마다 나는 다소 혹은 꽤나 독단적인 편이었다. 혼자 해낼 수 있다 생각이 들면, 남한테 맡기기보다 처음부터 끝가지 모든 걸 내가 다 하려고 했다. 스스로 알고 있던 부분이기 때문에, '그러지 말아야지!' 매번 생각은 하면서도 결국은 팀원을 믿어주고 기다리기보다 성격이 급해 내가 해결하는 편을 선택했다. 그리고 이번에도...

팀 프로젝트는 혼자 하는 작업이 아니라, 팀이 같이 하는 작업이다. 특히나 이 프로젝트는 연습 프로젝트이고 이를 통해 자바에 대한 개념을 탄탄히 하고 익숙해질 수 있는 기회였다. 나는 알고 있다. 내가 이번 프로젝트를 통해 많은 걸 배우며 성장했고, 코딩의 재미를 다시 한 번 알게된 너무 귀중한 시간이었다는 것을. 그러나 이 기회는 단순히 프로젝트를 한다고 얻어지는 것이 아니라, 막막함 & 어려움에 부딪히며 내가 무엇을 모르는지, 왜 이렇게 해야하는 지, 왜 오류가 나는지 스스로 해결책을 찾는 과정을 겪었기 때문이다.

근데 나는 혼자 그 과정을 겪으려 했고 팀원들이 해야할 파트마저도 내가 다 해버리곤 했다. 팀원이 어려운 부분이 있으면 어떻게 하면 좋을지 같이 생각하면서 스스로 해결할 수 있도록 도와줘야 했는데 그런 과정 없이 내가 해결을 하고 끝냈다. 그러다 아차! 싶어서 다시 팀원과 더 구현해야할 메서드들을 나눴고 문제가 있다면 같이 고민하고 직접적인 코드보다 수도코드를 작성하는 방식으로 도움을 주려 노력했지만, 처음부터 그렇게 했으면 어땠을까? 하는 아쉬움이 남는다.

설명을 잘해 봐!

이번 프로젝트를 하면서 중요하다고 깨달은 한 가지가 또 있다. 바로 설명이다. 팀원들에게 이것저것 설명을 해주거나 튜터님께 질문을 할 때 '와 나 말을 왜 이렇게 못하지?', '타인에게 설명하고자 하는 걸 정확히 무엇인지 나는 알고 알려주고 있는가?', '내가 무엇을 물어보고 싶은지 정확히 파악하고 있는가?'하는 생각이 들었다.

명확하고 분명하게 전달하는 것. 그래야 정확한 답변을 얻을 수 있고 상대도 쉽게 이해할 수 있다. 무언가 설명을 해야할 때는 내가 무엇을 말하고자 하는지 정확히 인지하고 정리를 한 후에 말하려는 습관을 길러야겠다. 더이상 스스로도 혼란스러워 횡설수설하거나 듣는 이를 배려하지 못하는 설명은 Bye Bye.