[220614] 코드스쿼드 마스터즈 일일 회고

# 개발 프로세스

어제 회고 쓰고 난 뒤에 Agile 방법론에 대해서 찾아봤다.

Agile 방법론에 대해서 좀 더 자세히 알고 나니 코드스쿼드 교육 과정이 얼마나 Agile 함을 지향하고 있었는지 알 수 있었다.

 

그러면서 이번 3주 프로젝트를 어떻게 하면 조금 더 Agile 스럽게 진행 할 수 있을지를 함께 고민을 좀 해봤는데

우선 일단 지금까지 프로젝트에서 요구사항 분석을 하며 작성했던 User Story를 Product Backlog 라는 명칭으로 작성하고 Story 별 Task 목록을 작성하던걸 Sprint Backlog 로 이번 주의 스프린트에서 작업할 스토리만 선정하여 작성하면 좋을거 같았다.

Story 별 구체적인 Task 목록 또한 해당 스프린트를 시작 할 때 작성하는 걸로!

 

거기에 어제 회고에서 다짐한대로 기능을 개발 할 때도 현재 진행 중인 스프린트의 목표에 집중해서 구현하는걸 목표로 하면 조금 더 Agile 스러워 질 것 같았다. 그래서 오늘 도니와 얘기를 해서 우선 아래와 같이 Product Backlog와 이번 주 Sprint Backlog를 작성해봤다! ^0^)g

사실 기존에 작성하던 User Story 와 내용은 큰 차이는 없긴 하지만 작성 시점과 수정 시점을 명확히 하는 차이를 뒀다.

지금까지는 프로젝트 요구사항 분석 단계에서 모든 Story와 Story의 Task를 우다다다하고 전부, 최대한 생각나는대로 모든 경우의 수를 고려하여 구체적이게 다 작성을 해놓고 기능 개발을 시작했었다.

그렇게 초반에 상세하게 구체화 해놓으면 프로젝트의 전체 개발 기간을 추측하거나 뭐 그럴때는 좋다고 생각은 하지만

일단 이번 프로젝트의 기간이 3주고 그 안에 모든 기능을 구현 할 수 있다는 보장도 없고,

딱 이번 한 주, 이번 스프린트에만 집중한다 생각을 하니 이번 스프린트에서 구현하는 기능 외의 요구사항에 대해서는 딱히 고려를 할 필요가 없는 것 같았다.

 

그래서 Product Backlog를 프로젝트 전체의 Todo 리스트라 생각하고 대략적이고 큰 범위로 쭉 작성을 했고,

그 중에서 이번 스프린트에서 구현하려고 하는 로그인 기능과 관련 된 Story만 따로 분류해서 각 Story 별 세부 Task를 구상해서 작성해봤다.

 

그리고 기능 개발 시에 현재 스프린트의 목표에만 집중하는 부분은 원래 지금까지 프로젝트 개발을 시작하면 우선 전 페이지에 걸쳐서 사용되는 버튼이나 Input, Label 같은 공용 컴포넌트들을 싹다 만들고 난 뒤에 페이지 레이아웃 개발을 시작했다.

그렇게 사전에 모든 컴포넌트를 다 만들어 놓는다면 이후 여러 페이지의 레이아웃을 만들때 빠르게 만들 수 있었고, 모든 디자인의 경우의 수를 고려해서 각잡고 만들기 때문에 컴포넌트의 코드가 디자인 때문에 나중에 수정되는 일이 없어서 좋았다.

다만 그렇게 할 경우 첫 주에는 컴포넌트들만 만드는데 대부분의 시간을 써야 했다는 단점이 있었다. (특히 Atomic 을 시도 할 때가 대박이었는데...)

 

 

그런데 만약 로그인 페이지에만 집중을 한다면 로그인 페이지에서 필요한 컴포넌트는 딱 Button과 Input 컴포넌트 뿐이었다.

(위의 그림에서 첫번째 스케이트 보드를 만드는데 바퀴와 보드만 필요하지 킥보드의 핸들이 필요 없는 것 처럼?)

그래서 이번 스프린트의 목표가 로그인 페이지의 구현이라면 그 외의 컴포넌트들은 지금 만들어봤자 필요 없는게 아닌가 목표를 벗어나는게 아닌가라는 생각이 들어 도니와 논의 한 끝에 로그인 페이지에서만 필요한 Button과 Input 컴포넌트만 우선적으로 개발하고 바로 로그인 페이지 구현에 들어가기로 결정했다!

 

이게 정말 Agile 스러운건지는 모르겠지만 여튼 쨋든 ㅎvㅎ) 나쁘진 않은거 같다!

이렇게 3주 동안 진행해본 뒤에 이 방식의 장단점을 회고해보면 좋을거 같다!

 

# Github OAuth

Agile 방법론을 좀 학습 해본 뒤 이번 주 구현 해야 하는 Github OAuth의 흐름을 공부해봤다.

사실 Github OAuth를 거의 2달 전에 했던 프로젝트에서 추가 도전 과제 같은 미션으로 구현 해볼 기회가 있어서 한번 찾아본적이 있었는데 그때는 React Router 에 대해서 잘 몰라서 url에 따른 분기처리나 뭐 그런걸 어떻게 해야 할지 몰라 잘 이해가 가지 않았었다.

그런데 지난 자판기 미션을 통해 React Router 를 사용해보고 나니까 그때에 비해서는 좀 더 클라이언트 쪽에서 어떤 식으로 로그인 과정을 처리해야 하는지 이해할 수 있었다!

그땐 정말 이걸 도대체 어떻게 하라는거지? 뭘 하라는거지? 하고 이해가 안갔는데 이번엔 왠지 할 수 있을거 같다!

별거 아닌거였을지도!! ^0^)!!!

내일 백엔드의 Sammy에게 어떤 흐름으로 구현할 예정이신지 여쭤보고 프론트도 그에 맞춰서 로직을 결정하기로 했다!ㅎㅎ

 

# 사용자성을 고려한 data fetch 시점에 대한 고민

오늘 이번 주 목표 범위인 로그인과 이슈 목록의 요구사항을 분석하면서 도니와 사용자성을 중점으로 어느 시점에 어떤 데이터를 fetch해오는게 좋은지에 대해서 많이 고민을 했다.

여러 데이터에 대해서 고민을 했는데 결과적으로 고민을 하게 된 주요 포인트는 3개였다.

 

언제 사용자가 이 데이터를 처음 사용하는지?

이 데이터는 자주 사용되는 데이터인지?

데이터가 변경 될 가능성이 높은지?

 

이 고민들에 따라 내린 결론이 최초 data 를 fetch 해오는건 사용자가 데이터를 처음으로 사용 하려고 할 때 받아오기로 했고,

데이터가 자주 사용되는 데이터라면 가급적이면 사용하려고 할 때마다 계속 서버에서 fetch를 받아와 최신 상태로 만들어주는게 좋지만 만약 변경 될 가능성이 그닥 높지 않다면 한번 fetch 받아온 데이터를 caching 하여 사용하기로 했다.

 

지금까지 코드스쿼드에서 매번 미션을 할 수록 처음에는 내가 구현하기 편한 방식을 먼저 생각하다 점점 사용자의 입장을 고려해나가는 것 같다. 특히나 이번 미션에서 시작하기 전에 기대했던 대로 도니는 늘 사용자의 입장을 깊게 고민하기 때문에 이번에도 도니 덕분에 여러 방면으로 고민 해볼 수 있었다.

 

# 고민 기록

Notion에 고민 카테고리를 추가했다!

사소한 고민 하나하나를 도니와 함께 하면서 그 과정을 마치 페어 프로그래밍처럼 도니가 고민 내용을 정리해서 말해주면 그걸 내가 노션에 타이핑하면서 정리했다!

환상의 호흡 굿 ^_^)b

 

---

도니가 알려준 css 관련 깨알 지식

  html {
    font: ${FONT.WEIGHT.REGULAR} 62.5%/1.5 ${FONT.FAMILY.BASE};
  }

  body {
    width: 100%;
    color: ${COLOR.title};
    font: inherit;
    letter-spacing: -0.4px;
    font-size: 1.6rem;
    background: ${COLOR.background};
  }

폰트 한 줄로 작성하는 법이랑

62.5%의 이유 -> rem 기준인데 브라우저가 16px? 기준인걸 10px로 고정해줘서 rem을 쓸때 16px이면 1.6rem 이라고 편하게 쓸 수 있게 설정

1.5 line-height

letter-spacing -0.4px 은 자간 보기 좋게 기본으로 0.4로 설정

버튼의 width 속성을 min-width로 설정하는것 -> 일종의 확장성을 고려한 예