[carsharing-40] 오브젝트를 읽었지만...

최근 지인들과 오브젝트 책을 읽고 책 내용을 적용해 객체 지향적으로 토이프로젝트를 만들고 있다. 주로 퇴근 후 저녁시간에 나랑 비슷한 실력의 팀원들과 같이 페어프로그래밍을 진행하고 풀리퀘스트를 날리면 리뷰어분들이 리뷰를 해주는 형식으로 진행된다.

https://github.com/Chanqun-Co/carsharing/pull/44

carsharing-40 스케쥴 엔티티 설계 by NewEgoDoc · Pull Request #44 · Chanqun-Co/carsharing

그런데 엊그제 문제가 발생했다. 해당 이슈는 2주 전부터 질질 끌고 있다보니 점점 스파게티 코드가 되어가서 하나를 수정하고 다시 보면 다른게 엉켜버리는 악순환이 발생하고 있었다.

결국 팀장의 전원 호출이 떨어졌다.

디스코드 집합!

 

설계 초기에는 예약 테이블 하나로 예약을 관리하므로 시작시간과 끝시간 값을 예약이 관리하고 있었다. 그 후 프로젝트를 진행하면서 따로 일정을 관리하는 테이블이 생기게 되었고 이 일정 테이블에서 시간을 관리하는걸로 변경하기로 결정했다.

그런데 예약에 시간 필드를 그대로 놔두게 되면서 일정이 생성될 때 예약의 시간 필드가 필요하게 되어 예약과 일정 테이블의 결합도가 높아지는 오브젝트 책의 저자 조영호님이 말씀하시는 안좋은 코드가 만들어지게 되었다...

문제의 시작점!

그렇게 만들어진 코드는 다음과 같다.

문제의 코드

일정이 생성될 때 올바른 시간인지 검사를 하는데 이때 가져오는 시간이 예약에서 시간을 꺼내서 판별한다. 오브젝트 책의 초반부에 나오는 안좋은 예시 코드 중에 티켓을 검사하기 위해 가방에서 꺼내는 코드가 있는데 우리가 작성한 코드랑 완전 판박이다! (덧 - 검사 함수명도 정각인 시간만 가능하다는 정책과 통일하여 네이밍하였는데 이렇게 데이터에 종속된 네이밍 보다는 checktime과 같이 행위에 관한 네이밍이 좋다고 한다.)

솔직히 책을 읽으면서 "누가 이렇게 코드를 짜지 저자분이 너무 억지 상황을 만드는거 아니야?" 라고 생각했던 적이 있는데 그게 나였다.ㅋㅋㅋ 반성해야겠다.