메인 프로젝트 회고

꺄악 운석이다·2022년 10월 8일
0
post-thumbnail

좋았던 점

1. 실전 경험

사실 이게 프로젝트에서 얻은 것 중 가장 큰 부분을 차지할 것이다. 프로젝트 전 까지는 배우는 것에 집중했다면 프로젝트에서는 직접 기획부터 배포까지 모든 과정을 거쳐보았고 이 과정에서 여러 뻘짓(?)들을 통해 프로그래밍의 전반적인 이해도와 실력이 확실히 증가했다는 것을 알 수 있었다.

2. 커뮤니케이션 스킬 향상

개발자들에게 중요한 스킬은 기술 스택 뿐만이 아닌 소프트 스킬 또한 중요하다고들 한다. 페어프로그래밍을 하면서 몇번 다른 사람과 협업을 한 적은 있었으나 프로젝트 전까지는 그 말에 크게 와닿지는 않았다. 그러나 프로젝트를 통해 커뮤니케이션 스킬이 중요하다는 것을 깨닫게 되었다. 20 + n 년간 다른 환경에서 살아오다가 갑자기 하나의 목표를 향해 달려가다보니 서로 갈등이 생기는 것은 어찌보면 당연한 일이었으나 이를 해결해 가면서 팀원을 설득하고 서로 격려하는 방법을 익힐 수 있었던 것 같다.

아쉬운 점

1. 프로젝트 진행 시 설계의 중요성과 의견 조율의 필요성

.

우리의 프로젝트는 강아지 호텔 예약 서비스를 주제로 삼았고 방의 크기마다 방 갯수를 다르게 하기로 설계를 했었다.

그러다 프로젝트 중간 쯤 강아지는 사이즈에 따라 가격을 다르게 받는다고 팀원이 의견을 내었고 팀원들과의 의견 조율 끝에 방 갯수는 통합하고 사이즈(소형견, 중형견, 대형견) 에 따라서 가격만 다르게 하기로 결정을 내었다.

이때부터 문제가 발생하였다. 방의 갯수는 통합되었으니 총 방의 갯수를 Room(방) 엔티티에 저장 할 수 없는 상황이 되었고 그렇다고 방의 갯수를 Hotel(Company)에 넣기에는 Post(게시물)과의 연관성이 떨어지니 처음에 의도를 한 ERD 설계와 동떨어지고 연관관계가 매우 이상해지는 결과가 나타났다

결국 프로젝트 중반에 엔티티 구조를 뒤엎을 순 없어서 Post엔티티에 총 방의 갯수를 넣기로 결정하였다.

이번 프로젝트에서 가장 아쉬웠던 점인 것 같다. 프로젝트 초반의 확실한 설계가 중요함을 깨닫게 되었다.

+) 이후 프로젝트 리팩토링을 하면서 Room엔티티에 대해 다시 고민하게 되었고, 결국 프로젝트 초반의 설정대로 하기로 결정하였다.


2. 클린 코드의 중요성

메인 프로젝트 시작 후 벡엔드 간의 역할 분담을 하게 되었고 나는 Post와 Reservation 기능 구현 부분을 맡게 되었다.

다른 팀원들과 달리 여러가지를 고려해야 할 점이 많았어서 일단 구현이라도 해보자 라는 생각으로 클린 코드와는 거리가 먼 코드를 짜게 되었다.

이후 팀원들과 통합하게 되었고 팀원들이 내가 쓴 코드가 필요할 때 팀원들이 내 코드를 알아보기 힘들게 되었고 그때마다 설명을 해줘야 하는 상황이 오게 되었다.

팀원들이 내 코드를 읽는 모습

팀원들이 내 코드를 읽는 모습

결국 리팩토링을 통해 코드를 정리함으로써 더 가독성 있는 코드가 되었으나 처음부터 변수명이나 메서드의 역할 분리를 확실히 했었으면 하는 아쉬움이 남게 되었다.

  • 2022.12 ) 이후 우테코를 통해 읽기 좋은 코드에 대해 깊게 고민하게 되었고 작게는 의미있는 이름 설정부터 단일 책임 원칙 등을 고려하면서 다시 리팩토링을 하였다. 덕분에 저번보단 읽기 좋은 코드가 된 것 같다.

3. 지식 부족으로 도입하지 못한 기술

프로젝트 진행 중 별점 시스템을 도입하게 되었는데 페이지 단위로 정렬 시 별점을 불러오는 방식을 어떻게 할지 의논하게 되었다.

총 네가지의 방법이 제시되었는데
1. 페이지 조회 때마다 별점 계산 후 평균 별점 값 내보내기
2. 평균 별점을 미리 저장 해 놓은 후 페이지 조회할 때 내보내기
3. 처음 100개의 별점만 계산해서 평균 별점 값 내보내기
4. 스프링 배치를 이용해서 특정 시간에 한번에 계산하기

총 네가지 방법 중 첫번째 방법은 너무 비효율적이었고 세번째 방식은 기업에서 처음에는 평이 좋았다가 나중에 안 좋아지는 경우 기업에서 컴플레인(...)을 걸 수 있다는 조언 덕분에 2번과 4번의 의견이 남게 되었다.
팀원들의 의견은 2번이었으나 나는 개인적인 욕심과 스프링 배치 도입시 응용할 수 있는 부분이 많을 것 같아 4번을 생각했으나 일단 2번으로 가고 4번은 개인적으로 스프링 배치를 공부한 이후 적용해도 늦지 않겠다고 판단해 별점 계산 방식은 2번으로 하게 되었다.

이후 프로젝트 기간동안 여유가 생길 때마다 스프링 배치를 공부해보았으나 생각했던 것보다 러닝커브가 높았고 결국 프로젝트 진행에 밀려 흐지부지 되고 말았다.

스프링 배치는 추후 개인 프로젝트나 배울 수 있는 기회가 되면 사용을 해보겠다.

profile
멸종은 면하자

0개의 댓글