너무도 힘든 2차 프로젝트가 끝이 났습니다.
2주간 13개의 API를 구현하며 다른팀보다 더 많은 기능구현과 많은 오류를 접하게된 좋은 경험이였습니다.
프로젝트 간략 소개
호텔예약을 지원하는 숙박업 예약 사이트
협업툴 : Github, Notion, slack, Trello
WorkProcess : ScrumProcess
- 개발자 구성
- 프론트 4명
- 백엔드 2명 - 백엔드 기술스택
- AWS EC2
- AWS RDS
- Python & Django
- MySQL
원활한 소통
저희팀은 프론트 4명 백엔드 2명으로 프론트개발자 2명의페이지를 백엔드 개발자 1명이 담당하는 식으로 업무했습니다.
매일 오전 프론트 개발자들과 1대 1로 기획, 요청사항들을 맞추어 나갔습니다.
이런 정말 너무 좋은것들이 몇가지 있었습니다.
- 본인의 능력에 따라 가능, 불가능의 여부 혹은 진행속도들을 공유하기
- 모르는 부분이 있다면 서로 공부를하고 다시 회의 하기
- 프,백 둘이 손잡고 멘토님 찾아가기
진행상황을 공유하며 생각의 차이가 있거나 모르는 부분이 있다면 서로 더 공부하고 다시 회의하고
특히나 너무 열정적인 분들이라 본인의 역량에 대해 정확히 파악하고 있고 본인의 코드에대해서도 파악하고 있어서
통신과정에서 양측 모두 디버깅을진행하며 원할한 소통을 이루며
수시로 작업 진행과정을 공유하며 조율점을 찾아나가는 과정은 너무나도 값진 과정이였습니다.
회원가입은 있는데 로그인이 없다??
이번 2차프로젝트에서 모든팀은 카카오 API를 이용하여 소셜로그인 기능을 구현 하였습니다.
자연스럽게 일반 서비스 로그인 기능은 하지 않게 되었고
저희팀도 서비스 회원가입기능만 구현하고 로그인 기능은 구현하지 않기로 했습니다.
하지만 아무리봐도 로그인 없는 회원가입 기능은 너무 무의미한 기능 같았습니다.
그리고 실제로 회원가입을 하고도 소셜로그인으로 인증을 강제로 하는 서비스들을 몇몇 본적이 있었습니다.
담당 프론트 개발자분에게
- "이건 유저입장에서 너무 불필요한 요소인거 같아요"
- "회원가입 기능보다 예약기능을 하는게 어떨까요~?!"
하는 저의 요청에 충분히 생각하시고 제 생각에 동의해주시며 예약기능을 하기로 하셨습니다.
예약기능은 추가구현 사항이지만 제가 요청한만큼 필수기능처럼 열심히 만들겠다고 약속 하였습니다.
프론트 개발자분의 결정덕에 서비스 전반적으로 <예약불가>기능이 추가되었습니다.
클래스 만들어보기
위코드에 와서 프로젝트들을 진행하면서 소원이 하나있었습니다.
이러한 유효성 검사 모듈을 한줄로 처리하는 것이였습니다.
리소스가 추가될때 마다 views.py의 코드가 한줄씩 늘어나는것이 마음에 안들었습니다
dict 와 validator의 클래스화로 한줄의 코드로 줄이는데 성공하였고 그 코드는 아래와 같습니다.
views.py 부터 보면 CONFIG라는 dict에 유효성 검사를 할 각 데이터를 list로 받아옵니다.
제 코드 기준으로 같은 정규표현식으로 유효성검사를 하는 데이터들을 list 형태로 넣으면됩니다.
key값은 validator의 self.action과 일치시켜줍니다.
validators.py 를 보면 반복문을 돌면서 validate함수들을 호출하고 평가합니다.
이렇게 하여 저의 views.py의 코드는 가벼워졌고 OOP의 코드의 재사용성과 유지보수의 우수성을 보며 감탐만 나왔습니다.
개발 공부를 시작할때 작은 소원이였지만 그 소원을 이루면서 너무도 많은것을 얻고 칭찬도 덤으로 얻었습니다...
왜 꼭 그렇게 해야합니까!?
이번프로젝트에서는 merge 가 아닌 rebase 키워드로 commit 관리를 했습니다.
rebase를 사용하면서 한가지 궁금한 것이 생겼습니다.
rebase를 사용하면 어디서 branch를 만들던 다시 main 브랜치로 커밋이 이어지는거 아닌가?
그러면 최신 브랜치에서 새로운 브랜치를 만들어도 되는거 아닌가?
그렇게 저는 하지 말아야 할 짓을 했습니다..
주말간에 최신브랜치에서 브랜치를 새로 만들며 8개의 API를 구현하였고 그결과 1개의 commit에 그간 작업했던것이
file change에 반영되며 무지막지한 일이 벌어졌다..
위의 사진은 S3와관련한 셋팅 파일이다 (S3는 리뷰기능에서만 사용하였다.)
전혀 상관없는 곳에서 계속 계속 fileChange에 표시되며 멘토님이 굉장히 어지러워하셨고...
이를 해결하기위해 새로운 브랜치에다가 코드를 복사하는것을 7~8개 브랜치에서 하였다....
안하는데는 이유가 있었고... git은 역시 어려웠다....
하지만 cheryPick이란 기억너머 저편에 존재하던 키워드의 활용법을 알게되었다.
(하루를 내어주고 cheryPick을 얻었다..)
No Pain No Gain
이번 프로젝트는 아는것을 활용하기보단 새로운것에 도전하는 프로젝트였습니다.
- 테스트 코드 작성
- 카카오 소셜 API
- AWS S3
이로인해 되게 사소한 부분에서 오류도 많이 발생하였습니다.
공부와 적용을 동시에하는 값진 경험이였습니다.
한편으로는 업무분배의 미스로 인해 과한 양을 담당해야하기도 하는 프로젝트였습니다.
하지만 많은 양의 업무더라도 내가 가진것을 활용하여 무언가를 만들고 그결과를 보았을때의 만족감은
이전에 해왔던 일들에서 느낄 수 없는 너무 만족으스러운 경험이였습니다.
'프로젝트 > 위코드' 카테고리의 다른 글
[Wish Korea]RESTful 한 end point 설정하기 (0) | 2022.07.10 |
---|---|
[Wish Korea]프로젝트 회고 (0) | 2022.07.03 |
[Wish-Korea] 프로젝트 ERD (0) | 2022.06.26 |
[Wish-Korea] Start!!! (0) | 2022.06.26 |