우아한테크캠프 4기 두 번째 프로젝트 회고

저장소 링크

배포 링크

 

이번 회고는 저번의 회고에서 개선한 방식을 적용해보기로 했다. :)

 

학습 키워드

 

1. history와 SPA

  pushState, replaceState

 

2. 개발 환경과 배포 환경을 나눠서 구현하기

 

3. s3를 사용한 정적 웹 페이지 배포

빌드한 파일을 s3에 업로드해서 배포한다는 생각을 해보지 않았었는데..

역시 사고는 개방적이야 한다. :)

세번째 프로젝트에서 ec2가 많이 아파서 Nginx를 사용해서 빌드된 파일을 서빙하고 있는데 s3를 활용해보면 어떨까 하는 생각이 든다.

 

4. sass:map

sass에 대한 욕심이 생겨서 새로운 시도를 해보다가 찾았는데 두번째 프로젝트 환경에서는 굳이 필요하다는 느낌은 받지 못했다.

기존의 방식이 아닌 새로운 방식의 시도를 해본 것으로 만족!

 

5. passport

단순히 소셜 로그인 구현할 때, 사용하는 패키지로만 알고 있었는데 serializeUser, deserializeUser라는 키워드를 접하고 내가 그동안 너무 얕게 알았다는 생각이 들었다.

 

Keep

 

1. 먼저 다가가기

당연한 얘기지만 민상님과는 팀원이 되고 나서 처음으로 얘기를 나누게 됐다.  

교육이지만 이 프로젝트도 하나의 업무라고 생각이기에 자유롭게 얘기할 수 있는 분위기를 형성하는 것이 중요하다고 판단했고, 간단하게 아이스브레이킹 시간을 가지자고 먼저 말씀드렸다.

내 자신이 워낙 내성적이지만 취미나 관심사, 요즘 하고 있는 고민 등 얘기를 먼저 꺼내보니 빠르게 거리감을 해소할 수 있었다.

그런데 헬스가 취미라고 하셨는데 주말에도 서로 열심히 하다보니 한 번도 헬스를 못하신 거 같아서 미안했음 :)

 

2. 옵저버 패턴 ;)

이번에는 서로 어디까지 진행했는지 수시로 확인하면서 프로젝트를 진행했다.

처음에 협의된 내용은 아니었고, 따로 체계가 존재하지는 않았다.

그런데 민상님이 주기적으로 어디까지 했는지 말씀을 해주셔서 같이 오프라인에서 진행하지는 못했지만 페어의 진행 상황을 원활히 파악할 수 있었고, 나 또한 그런 모습을 배워서 협업 방식을 개선할 수 있었다.

 

 

Problem

 

1. 사라진 코드 리뷰

첫날, 풀리퀘스트 요청마다 코드리뷰를 진행하기로 협의를 했지만 기능 구현에 대한 시간이 촉박하다는 핑계로 결국 코드 리뷰는 사라지고 말았다..

 

코드 리뷰가 사라지면서 풀리퀘스트, 커밋 컨벤션을 지키지 않는 문제도 함께 발생하게 됐다.

 

2. 무의미한 코드 리뷰

어떻게든 코드 리뷰를 진행하려다 보니 코드 리뷰를 위한 코멘트를 대충 작성하게 됐고, 이런 부분도 1번의 문제가 발생한 원인 중 하나였다.

(그런데 지금 와서 몇몇 리뷰를 확인해 보니까 나름 영양가 있는 녀석도 있었네!)

 

그래서 어쩌다가 이렇게 됐나 회고를 하게 됐고, 그 이유를 정리해봤다.

1. 여기서 코멘트를 해도 될까?
 정말 사소한 부분에 코멘트를 다는게 옳을까? 예를 들면 z-index를 2나 3정도로 설정해도 됐는데 굳이 100이라는 숫자를 쓴 이유? 혹은 slice에 왜 매직넘버가 존재하는지 같은 것들...
지금은 이런 부분에도 코멘트도 필요하다고 생각하는데 그 당시에는 굳이 얘기할 필요가 있나 라는 생각이 들었다.

2. 내가 아는게 정답일까?
 잘못된 부분에 대해서 개선을 요구하는 코멘트를 작성할 때, 사실 내가 잘못 알고 있는 것이었다면? 이라는 생각때문에 상당히 방어적인 태도를 가지게 됐고, 코멘트 하나를 작성하기 전에 짧게는 몇분, 길게는 한시간씩 시간을 소모하면서 상당한 피로를 느끼게 됐다.
이로 인해 시간이 촉박하다는 핑계가 나왔음!
물론 불확실한 내용으로 코멘트를 작성하지 않는 태도는 매우 좋은 자세라고 생각하고 있기에 이 부분은 유지하기로!

어쩌다보니 회고 안의 회고 같은 녀석이 됐다!

 

 

Try

 

1. 코드 리뷰를 두려워하지 않기, 하나의 PR에는 하나 이상의 코드 리뷰를 작성하기

두 번째 프로젝트에서 가장 아쉬웠던 부분인 코드 리뷰는 코멘트를 거리낌 없이 달기만 해도 괜찮지 않았을까 싶은 생각이 들었고, 이번에 진행 중인 프로젝트에서는 코드 리뷰를 꼭 작성하는 방향으로 프로젝트를 진행하고 있다.

먼저 코드 리뷰를 두려워하지 않는 점은 마음 가짐이고.. 명확하게 달라진 점은 작업 내용을 파악하는 시간을 줄일 수 있게 풀리퀘스트 템플릿을 작성하여 작업 내용을 명시하도록 했고, 덕분에 시간이 절약돼서 그런지 현재까지 원활한 코드리뷰를 진행하고 있다. :)

이전보다 PR 하나당 리뷰 갯수도 증가했다!

 

2. 하루에 다른 팀의 코드를 최소한 한 팀 이상 관찰하기

같은 주제로 프로젝트를 진행하는 만큼 다른 팀의 코드를 볼 때, 내가 생각하지 못한 방식으로 구현하는 모습을 확인할 수 있었다.

코드스쿼드에서도 생각은 하고 있었지만 시간이 부족하다는 핑계로 실천하지 않았었다.

그래서 이번에는 개선해보려고 한다.

금요일까지 총 4개의 팀의 코드를 봤는데... 목표 미달이므로 주말에 열심히 관찰해볼 예정!