구방문방구 | 프로젝트 회고

Project 구방문방구(9roomdroom9)

 

 

1. 프로젝트 개요

앞뒤가 똑같은 구방문방구를 팀명으로 팀원들의 물건을 재미있게 판매하는 서비스 홈페이지 구현

배민문방구 홈페이지를 클론 코딩하며 기본적인 user flow를 구현하는 것이 목표

짧은 기간 개발에 집중하기 위해 기획, 디자인을 참고하고 모든 기능은 0부터 직접 구현

메인 회원가입/로그인 상품리스트 상세페이지 장바구니 + 검색기능 구현 후 aws이용해서 배포

 

배포주소

구방문방구 클릭하면 이동(요금부과로 삭제)

 

개발 기간

2022.07.18 ~ 2022.07.29(2주)

 

개발 인원

프론트 3명, 백엔드 2명

 

내 역할(백엔드)

백엔드 github

DB모델링, API 구현(상품목록(정렬, 페이지네이션, 검색), 카테고리, 상품상세), AWS배포

 

사용 기술

FE | HTML, CSS, SASS, JavaScript, react

BE | python, django, MySQL, Postman

공통 | AWS

 

협업도구

git & github : 각자 기능을 브랜치에서 구현하고 문제없이 완료된 기능만 main에 merge되도록 했다.

Trello : 티켓을 나누어 작업상황을 한눈에 볼 수 있도록 했다.

• Backlog: 프로젝트 기간동안 완료해야할 티켓(프로젝트 기간이 짧기 때문에 추가구현사항은 따로 이름을 붙이고 필수사항 위주로 구현)
• To-Do(This Sprint): 이번 스프린트(1주일 간격)동안 완료해야할 티켓
• In-Progress: 진행중인 작업들
• In-Review(PR): 깃허브에 PR을 올리고 리뷰, merge 대기중인 완료작업들
• Connection(F-B): 백엔드-프론트엔드 통신이 완료된 작업
• Done(Merge): merge가 완료된 작업들

Notion : 회의록 작성, api명세서 공유 등 용도로 사용했다.

Slack : 팀원간 소통을 위해 사용. github 레포지토리와 연결해서 코드리뷰 진행상황 파악

 

시연 화면

메인

카테고리별 목록

정렬

 

 

2. 개인 회고(KPT)

keep

협업툴 활용

우리 팀은 노션과 트렐로를 잘 활용했다. 노션에는 회의록과 api명세서를 작성하고, 참고 자료등을 공유하는 데 사용했다. 트렐로의 done 기준을 확실하게 한것, 기능 구현후 프론트-백엔드 통신 여부도 티켓을 따로 추가한 것 등도 잘 했다고 평가받았다. 

앞으로 2차 프로젝트나 다른 프로젝트를 할 때도 도움이 될 것 같다. 

 

배운것들 잊지않기

프로젝트를 진행하면서 혼자 고민하고 검색하고 리뷰를 받으면서 배웠던 것들을 잊지 않도록 할것이다.

초기세팅을 세번이나 하면서 생겼던 문제점들과 그 이유와 해결방법들(전부 깃관련...)

프론트에게 줘야할 값들

orm 최적화

요청으로 들어온 값을 할당하는 코드 위치

깃 커밋메세지 적절하게 작성하는법 등등 사소한것 같아도 모두 중요한 것들이라서 잊지 않고 계속 가져가고 싶다.

 

problem

회의록 작성

노션에 회의록 페이지는 있었지만 아무도 회의때 실시간으로 회의록을 작성하지 않았다. 멘토님이 같이 하신 미팅때는 우리끼리 한번, 멘토님하고 한번 두번이나 했는데 기록된 회의록이 없어서 아까 무슨말 했었지? 생각하면서 회의를 진행했다. 

지적을 받은 후로 매일 어제한일, 블로커, 오늘 할일에 대해 각자 작성하고 회의를 했는데 미리 생각해놓고 작성한 기록을 가지고 회의를 진행하니까 내가 말할때도 훨씬 수월하고 다른사람의 진행상황이 더 잘 들어왔다.

그리고 프로젝트를 진행하면서 내가 작업한 내용을 틈틈이 정리하지 못했는데 회의록 작성이 잘 돼있어서 지난 회의록을 보면서 뒤늦게라도 보며 정리할 수가 있었다. 첫째주에 피드백을 받고 반영해서 다행이었다.

 

프론트엔드와 소통

api명세서도 마찬가지로 처음부터 작성을 잘 했던게 아니라서 초반에는 통신때 최초로 프론트엔드 분들과 소통을 하고 엔드포인트를 맞추고 키를 맞추고 했던 기억이 있다. 다들 첫 프로젝트라서 미리 맞춰볼 생각을 못한것 같은데 소통의 중요성을 깨달았다.

 

꼼꼼하게 확인하기

git conflict를 해결하면서 누락된 코드가 있었고

프론트엔드에게 반환해줘야 하는 값이 여러번 중복으로 들어간 것도 있었고 줘야할 값을 안준적도 있었고

리턴해줘야 할 값을 미리 명세서 작성을 통해 생각해보는 것이 필요할 것 같다.

그리고 테스트를 할때 꼼꼼하게 처음 값만 확인하지 말고 다음 다음 확실하게 확인하고 pr을 올려야겠다.

 

남과 비교

프로젝트 진행을 하면서 내가 하고 있는게 맞는지 계속 확인하고 싶은 순간의 연속이었다. 그런데 누구한테 어떻게 말해야될지 모르겠어서  다른팀에서 같은 기능을 맡은 백엔드 동기들을 찾아가서 비교하고 내가 그들에 비해 한게 별로 없는것 같아서 고민했었다.

뭘 할지 모르는 상태가 무서웠던 것 같다. 지금 생각하면 블로그 정리를 할 수도 있었고 우리 페이지에 없는 기능이어도 어차피 남는 시간인데 그냥 그분들 고민 같이 해결하면서 한번 해볼수도 있었던건데 우리페이지에 없는 기능을 구현하려고 하는 동기들을 보면서 나는 그거 없는데 나도 해봐야되는거 아닌가 하면서 스트레스만 받고 결국 그 시간을 낭비한것 같아서 아쉽다. 페이지네이션도 계속 생각만 하다가 뒤늦게 구현하게 된 기능인데 다음엔 걱정만 하지 말고 걱정할 시간에 바로 해봐야겠다. 

 

걸걸걸

파이썬을 더 열심히 공부했어야 했다고 생각했다. 빈 문자열이 false인걸 생각 못해서 쓸데없는 코드를 추가한 적도 있고 파이썬은 null 대신 None이란걸 모르고 null로 써놓고 어 오류나네 안되네 했던 기억이 있다...그런의미에서 2차때는 코드카타를 진짜 1주일에 하나라도 풀어봐야겠다.

 

아쉬운 기능

정렬기능이 완벽하지 않아서 정렬버튼을 누르면 정렬된 10개, 그다음 스크롤로 넘어가면 기본정렬상태에서 11번-20번 상품이 나온다. 그래서 두개밖에 없는 상품이 3개가 나오기도 하는데 페이지네이션(무한스크롤)기능이 추가되면서 오류가 발생했는데 무한스크롤 기능이 마지막에 추가되면서 오류를 뒤늦게 발견해서 해결하지 못했다. 아마도 백에서 현재 정렬기준까지 리턴해주고 프론트에서 다음 요청에 정렬기준을 계속 주면 될것같은데 다음 프로젝트가 있어서 고치지 못할것같아서 아쉽다.

 

try

기록하기 소통하기

결국 기록이랑 소통이 전부인것같다. 다음에는 시작부터 확실하게 회의록 명세서 등을 작성해야겠다.

 

코드에 대한 고민

회고 미팅을 하면서 백엔드 팀원분이 처음부터 완벽한 코드를 만들고 싶은 욕심에 agile방식에 맞지 않게 작업을 한 것이 아쉽다고 했다. 

나는 그런 고민을 한 적이 없어서 그 말을 듣고 반성을 하게 됐다. 결국 그분은 혼자서 orm최적화까지 생각해서 코드를 짰는데 나는 코드리뷰 전까지 누가 알려주기 전까지는 그냥 기능 구현에만 집중했던것 같다. 두 방식을 섞어서 기능구현을 일단 한 다음 더 좋은 코드를 만들기 위해 고민하는 시간을 가져봐야겠다. 

 

그날그날 한 일들 기록하기

그날그날 적어둔 회의록을 보고 뒤늦게라도 프로젝트에서 내가 했던 역할을 돌아볼 수 있어서 좋았다. 기록의 중요성을 느꼈고 2차때는 개인 노션에라도 그날그날 한 일을 적어야겠다.

 

 

3. 마무리

회고를 하다보니 아쉬운 마음이 많이 든다. problems 분량만 엄청 긴걸 봐도...

하지만 시행착오가 결국 경험이 되는건데 회고를 하다보니 1차 프로젝트때 시행착오를 나름 많이 겪은 것 같아서 다행이다. 

 

그리고 프로젝트가 없었다면 몰랐을 것들을 많이 배웠다. 

데이터모델링때부터 어디까지가 백엔드의 역할이고 어디까지가 프론트엔드의 역할인지 모르겠어서 진행이 안됐었던 기억이 난다. 

그리고 처음에는 상품 정렬도 상품 리스트 슬라이싱도 본인이 하는거라는 프론트엔드 팀원 말에 그렇구나 했던 것도 기억이 난다. 이제는 이런 경계를 조금 알것같다. 

 

그리고 결국 모든것이 소통이란걸 깨달았다. 소통만 잘했으면 벌써 없어질 문제들이 한바가지다. 왜 개발자가 소통이 중요한 직업인지 알았다. 많이 들어본 말이지만 프로젝트를 통해 처음으로 와닿은 말인것 같다.

 

지금 회고한 것들을 잊지 않고 2차 프로젝트때 더 만족하고 싶다.