1차 프로젝트: 삼천리 자전거 cloning 및 추가 기능 구현

Demo 영상

To Youtube

회고록

좋았던 점:

1. 처음 보는 사람들과 협업을 할 수 있었고, 각자 열정도 넘치고 목표에 대한 기대치도 높지만 서로의 주장만을 고수하지 않고 타협 가능한 인원과 협업했다는 점.

2. 건강상의 이유로 작업에 방해를 받은 인원이 없었다는 점.

3. Standup meeting 전 각자의 어제 한 일, 오늘 할 일, 막힌 부분(blocker)를 trello 티켓에 정리해놓아 부수적인 대화 없이 서로의 작업 진행 상황을 공유하는 시간을 가질 수 있었던 점.

4. API 명세서를 꾸준히 업데이트하여 불필요한 소통을 최소화한 점.

   • API 명세서란?
     API 명세서는 프론트 엔드 개발자 분들이 무슨 URL에, 무슨 method으로, 무슨 정 보를 request header나 body나 query parameter에 담아 백엔드 단으로 요청 을 보내야 할 지와 그 결과로 무슨 타입의 무슨 내용의 데이터를 백엔드 단에서 프론트 엔드 단으로 전송하는지를 기록해놓은 문서입니다. 백엔드 API에 변경 사항이 있을 때 마다 명세서를 업데이트하고 프론트엔드 개발자 분들께 알려드림으로써 어디로 fetch해 야해요? 뭘 받는거에요? 이건 어디 써요? 등의 불필요한 대화를 줄일 수 있다는 장점 이 있습니다.

아쉬웠던 점

1. 원래라면 프로젝트 기간으로 8월 15일부터 8월 26일까지, 주말 포함 12일 정도의 시간이 주어졌어야 하지만 공휴일로 하루가 줄었고, 그 와중에 remote 서버에 PR들이 merge 되는 속도가 느려 시간적 여유가 부족했자는 점.

2. 프론트엔드, 백엔드 둘 다 초기 세팅을 만들 때 어디까지 공통 부분으로 만들어야 할 지, 어디부터 개인 작업 부분으로 설정 해야 할 지의 기준을 정하는 데에 있어 익숙치 않아 조금 혼란이 있었다는 점.

3. 아직 모르는 built-in method과 function들이 많은데 그것들을 검색하는 과정에서 키워드를 어떻게 선정해야 할 지 고민해야 하는 부분이 아쉬웠습니다. 그리고, 그런 고민하는 시간이 쌓이다보니 더 다양한 method과 function을 사용하여 똑같은 기능을 수행해도 더 짧은 runtime을 요구하는 소스로 refactoring해볼 시간이 부족했다는 점.

4. 개인적인 견해로 1차 프로젝트는 e-commerce site가 테마였던 것 같은데, 삼천리 사이트는 다른 후보 사이트들과 달리 구매/로그인등의 기능이 없는 단순 삼천리 제품 소개 사이트였습니다. 이 점을 인지하고 첫 팀 미팅 때, 장바구니 기능, 결제 기능, 로그인/회원가입 기능 등을 가지고 있는 다른 사이트를 reference로 선정해놨어야 했는데, 처음해보는 프로젝트이다 보니 이 과정을 거치지 않았습니다. 그 결과, 나중에 인지했을 때는 이미 작업이 너무 많이 진행되어있었고, 대대적인 수정 과정을 가지기엔 남은 작업 기간마저 여의치 않아 reference를 정하기조차 힘든 상황을 마주했던 게 정말 힘든 점 중 하나였습니다.

아쉬웠던 점들에 대한 개선안

(시간적 요인이나 환경적 요인은 불가피한 사항이기 때문에 개선 고려 대상에서 제외)

1. 초기 세팅 기준점에 대한 개선안

   • 초기 세팅은 말 그대로 작업 환경을 셋업하는 과정까지.
   • 개인의 선택에 따라 달라질 수 있는 사항이 포함된 부분부터 분기점으로 고려하기
     예시) Index.js는 모든 router가 포함되어 있고 조건문이나 무언가를 검사하는 기능이 없는 레이어이기 때문에 Index.js정도는 초기 세팅에 포함할 수 있다고 판단했습니다. 하 지만 API를 RESTful하게 설정하는 과정에서 개인의 선택에 따라 충분히 달라질 수 있는 부분이기 때문에 초기 세팅 사항에 포함될 수 없는 부분임을 배웠습니다.

2. 검색에 들이는 시간 소요 문제에 대한 개선안

   • 구글링으로 원하는 답을 바로바로 받아낼 수 없어도 최대한 시도해보기. 하지만, 시간을 정해놓고 시도해보는 습관을 기르기. 개발자 문화의 가장 큰 장점은 모르면 물어보는 것이 좋은 문제 해결 방안 중에 하나로 자리 잡혀있다는 것입니다. 그러니 예를 들어, 어떠한 문제에 직면했을 때, 딱 한 시간까지만 구글링과 접근 방식에 대한 고민을 해보고 풀리지 않으면 그 때 사수님이나 멘토님 등의 본인보다 숙련된 분께 '어떤 키워드로 검색을 해보 는 것이 좋을까요?', 혹은 '제가 이런 방식으로 접근해보고 있는데 다른 방식으로 접근해 보는 것이 좋을까요?' 등의 직접적인 답을 요구하는 것이 아닌 적당한 힌트 정도만 받을 수 있는 질문으로 난관을 해결해 나가는 방식을 채택해 보는 것이 좋겠다는 생각이 들었습 니다.

3. Reference의 부재 문제에 대한 개선안

   • 클로닝 프로젝트라면 말 그대로 목표를 클로닝하는 데에 중점을 두고, 혹시나 삼천리처럼 새로운 기능을 추가해야 하는 상황이라면 최우선 사항으로 어떤 기능을 가진 API를 만들 건지를 정하고, 그에 때른 referenc를 찾아놓기.