[Kernel 360] 해커톤 프로젝트 회고

kernel 360 과정 중에 3일 해커톤이 있었다. 

3월 10일부터 3월 12일인 오늘까지였는데, 오늘 오후에 발표였으니 실질적으로는 이틀이었다.

이전에 해커톤을 해보고 느낀거지만 정말 돌아가기만 하는 코드를 만들었다.ㅋㅋㅋ

 

 

 

https://github.com/Kernel360/KDEV4-Hackerton-seats-service/tree/develop

GitHub - Kernel360/KDEV4-Hackerton-seats-service: 6팀 회의실 예약 서비스입니다.

이번에 진행했던 프로젝트의 깃허브 링크.

3명이서 진행했고, frontend, backend 전부 같이 구현해야 했었다. (이전 dodream 프로젝트처럼)

배포까지 해보고 싶었지만 아쉽게도 로컬 환경에서만 진행이 가능하다.

 

 

 

 

 

프로젝트 소개

 

팀 프로젝트를 진행하면서, 회의를 진행할 때면 회의실을 미리 예약해서 진행해야 했다.

한 팀당 2시간, 오늘과 내일만 예약 가능한데 매번 수기로 쓰는게 너무 번거로워서 그걸 주제로 잡고 기획했다.

 

 

 

 

 

1일차

 

기획부터 기능 명세서, DB 설계까지는 나름대로 순조롭게 진행되었다.

당일 오전까지 완료해서 노션에 기록하였고 오후에 초기 세팅을 진행하고 바로 개발하기로 계획했다.

 

 

이런 식으로 노션에 작성하고 이대로 진행하기로 했었다.

 

첫 날에 내가 한 건 예약하기 기능과 예약 수정이었는데, 예외 처리 생각할 부분이 많았다.

단순하게 예약을 생성하는 것이 아니라 예외 처리가 필수였다.

 

• 하루에 2번 제한
• 중복된 시간 예약 불가능

 

이 두 가지 조건을 생각하고 했어야 했는데 단순 CREATE만 구현하고 예외 처리하느라 시간이 좀 걸렸었다.

이건 지금에서야 반성하는 부분이지만, 처음부터 조건에 대해 생각하고 미리 구현하는게 좋았겠다는 생각을 했다.

 

 

 

 

 

 

 

2일차

 

다음 날 오전까지 맡은 API를 구현하기로 계획했었다.

나는 수정 기능을 구현했지만, 기획상 제외하기로 하고 기능을 삭제하고 조회 기능을 계속 구현하고 결국 모두가 기능 구현 하고 프론트와 연동하기로 했다.

 

오후에는 jwt token으로 바꾼 로그인을 API에 적용하고 인터셉터를 만드는 등 시간을 다 썼다.

사실 중간에 merge 하고 코드가 중복되는 부분들이 있어서 그 부분을 수정하느라 오래 걸리는 바람에 계획보다 덜 진행되었지만 그래도 이번에 처음 코드 리뷰를 받아보았다.

 

 

 

이런 식으로 내가 구현한 코드에 대한 코멘트를 받았다.

사실은 라이브로 말하면서 진행했고 정리를 간단히 코멘트로 남긴 것이지만 아주 좋은 경험이었다.

 

지금까지 진행했던 프로젝트에서는 PR을 날리고 PR 규칙이 있긴 했지만,

대부분 '잘 확인했습니다' 라는 코멘트를 남기고 바로바로 merge 하면서 다른 사람 코드를 이해할 겨를이 없었다.

이건 나도 남의 코드를 공부하지 못한 잘못이지만, PR 알람이 울리면 다같이 코드를 보면서 리뷰할 시간이 있었으면 좋았겠다는 생각이 든다. 그러면서 다른 사람의 코드 방식 구현도 이해하고...

 

그래서 이번에 진행하면서 다른 분들의 코드 스타일에 대해 알게 되기도 하고, 보다 더 효율적인 코드에 대해 더 깊게 공부하는 계기가 되었다.

 

저녁에는 멘토님과의 멘토링이 있었는데 이게 정말 킥이었다.(!)

1시간 30분가량 진행되었는데 질문을 제외하더라도 코드 리뷰를 부탁드려서 받았는데 아주 많이 털렸다.

entity 설계부터 로직에 대핸 부분까지 지금껏 잘못 코드를 구현하고 있었다는 생각이 들었다.

이 부분은 해커톤 때문에 정신없어서 공부하지 못했지만 주말에 시간을 따로 내서 공부할 예정이다.

다양한 키워드들을 들어서 그걸 토대로 공부를 해야겠다.

 

아무튼.

이렇게 회의에 시간을 오래 쏟고 나니까 시간이 정말 없어졌다.

급하게 남은 API를 프론트에 연동하고 오류 처리하는 데 시간을 많이 썼다.

(덕분에 처음으로 집에 늦게 가게 되었다.)

 

 

 

 

 

 

 

3일차

 

대망의 마지막 날.

계획상 내가 배포를 맡아서 aws를 통해 진행하고 싶었지만...프론트와의 연동을 하지 못해서 우선 급한 불부터 끄고자 했다.

 

오전 내내 API 연동하고 잘못 설계된 API를 수정했다.

 

초록색 - 수정 전 / 주황색 - 수정 후

 

 

발표자료에서 가져왔다.

 

 

여기 보면 네모 쳐져 있는 부분은 고정이다.

그렇지만 이걸 그냥 UI라 생각하고 백엔드 쪽에서는 이쪽 데이터를 이용할 생각을 전혀 하지 않았다.

 

테이블 설계를 잘못했었지...ㅋㅋㅋ

회의실 내부 자리에 대한 생각을 하고, 시간에 대한 생각을 해서 그 두가지를 모두 고민했어야 하는데 그러지 못했다.

 

그래서 처음에는 프론트 쪽에서 그냥 시간 데이터를 전부 집어넣는 형식으로 진행했는데,

그렇게 하니까 너무 코드가 비효율적이었다.

결국 배포는 어쩔 수 없이 포기하고 이 부분을 고치기 위해 오전/오후 시간을 전부 다 썼다.

 

그래서 발표 자료를 만들 시간이 1시간이었는데, 그래도 발표를 성공적으로 마치고 해커톤이 끝이 났다.

 

 

 

 

 

 

 

KPT 회고

 

1. KEEP
   • 팀원들과 매일 스크럼
   • 소통 열심히 하기
   • 다른 사람들 코드 보고 이해하기
2. PROBLEM
   • 초기 기획 잘 하기
   • 테이블 설계 잘 하기
   • 프론트/백 연동 고민할 것
3. TRY
   • commit 컨벤션 정하기
   • PR 컨벤션 정하기
   • 배포 구현하기

 

이건 내 개인적인 KPT 회고이다.

팀원들이랑은 이미 다같이 회고를 끝냈고, 앞으로 다른 프로젝트 할 때 저걸 꼭 지켜야겠다.

 

이번에는 3일이었고, 시간이 너무 없어서 정신없이 구현했는데 앞으로는 그러지 말아야지.

시간 관리 열심히 하면서 우선 배포를 먼저 해야겠다.

 

전체 발표가 끝난 후 디렉터님이, 우선은 배포해서 다른 사람들에게 보여주는게 더 중요하다고 하셨다.

나도 그 생각에 동의하는게, 우리가 뭘 했다고 보여주려면 로컬 환경에서 실행시켜야 하는데 그게 문제가 많았다.

그래서 나중에 다른 프로젝트를 하게 된다면 어느정도 MVP를 구현한 후 배포를 해야겠다.

내가 아직 배포를 해본 적이 없어서 내가 하면 더 좋고, 다른 사람이 해도 옆에서 공부하면 되니까.

 

해커튼은 시간이 없는게 장점이기도, 단점이기도 하다.

집중해서 끝낼 수 있는 반면 나중에 보면 고쳐야 할 코드들이 한가득이니까.

비록 이번 프로젝트도 고치고 싶은 부분이 한가득이고 공부해야 할게 많지만, 3일동안 열심히 해서 좋았다.

아무래도...난 개발하는 그 순간이 좋은 듯 하다.