[컨셉비] 2. 1차 스프린트 과정 정리

1. 들어가기

컨셉비에 합류하고 총 5개의 PR을 머지하며 1차 스프린트를 마무리했다.

그 과정을 간단히 정리하고자한다.

2. 프로젝트 정리

합류했을 당시 프로젝트의 프론트엔드는 초창기 수준이었다.

마크업만 되어있고, api를 비롯한 기능이 붙여지지 않은 상태였다.

제일 먼저 도메인 분석을 하며 고칠 부분들을 정리해보았다.

2.1. 파일 코로케이션

먼저 파일의 배치를 코로케이션으로 적용하면 어떨지 제안했다.

코로케이션이란 어떤 페이지가 있을때 해당 페이지에서 쓰이는 컴포넌트나 훅, 타입 등을 그 페이지 폴더에 선언해두는 방법이다.

즉 가까운데서 쓰이는 것은 가까운데 배치한다로 정도로 받아들이면 된다. 

코로케이션

개발자들은 파일을 분리하고 배치하는 것에 스트레스를 받는데,

이렇게 하면 일단 파일을 분리할때 가까운데 둠으로써 머리 아플일도 줄어들고, 어떤 기능이 궁금하면 가까운데서 찾으면 되니까 편하다고 생각했다.

추후에 그 기능이 여러군데서 공통으로 쓰인다면 분리하면 된다.

물론 폴더가 많아지며 복잡해질수 있겠지만, 그 단점보다 장점이 많다고 생각했다. (또 한번도 시도해보지 않아 적용해보고 싶었다)

논의 결과 함께 하는 프론트엔드 개발자 1명도 괜찮다고 해서, 코로케이션을 적용하기로 했다.

2.2. api 명세

api 명세가 노션에 기록되어 있어 해당 api가 fresh 한지 알수 없었고, 의도치 않은 변경 위험이 있었다.

그래서 백엔드 개발자분들에게 이런 이유를 들어 REST docs나 swagger 적용을 요청드렸다.

2.3. 단순 리팩터링

페이지 파일명 작성 시 main.page.tsx, mainPage.tsx 처럼 확장자나 파일명 컨벤션이 통일되어 있지 않던 부분을 통일했고,

하드코딩되어 있는 부분의 리팩터링 필요성을 느꼈다.

3. 개발

3.1. 기능

게시글 작성 페이지와 게시글을 보여주는 피드 페이지를 작업했다.

각 페이지별 주요 기능은 다음과 같다.

• 게시글 작성: 많은 옵션이 있는 폼 제출
  • 제목, 내용 작성 시 글자 길이 제한
  • checkbox, dropdown, bottomSheet로 옵션을 추가하는 UI
  • 각 옵션은 백엔드에서 받아옴
• 피드 페이지: 최신 게시글과 인기 게시글 fetch
  • 무한스크롤 fetching
  • Intersection Observer와 react query의 `useSuspenseInfiniteQuery` 이용

3.2. 흐름

개발 흐름을 정리하면 다음과 같다.

1. 개발 범위 할당 (ex. 페이지 별로 할당)
2. 이슈 생성
3. 관련 디자인 확인 후 세부 정책 확인하여 이슈에 작성(세부 기능 개발 완료 시 지속적으로 업데이트)
4. 백엔드 api 논의 (공수 기간이 급하면 논의 전에 어느정도 api 형태를 예상해서 마크업 및 기능 뼈대 작성)
5. api 완성되면 기능 개발
6. PR 작성, 코드리뷰 후 머지
7. QA 후 기능 개선 및 버그 수정

현재 내 기준 특히 중요한 부분은 3번이라고 생각한다.

실제로 작성한 이슈(아직 배포되지 않아 모자이크 처리했다)

모든 프로젝트 관련자들이 현재 프론트엔드 개발 상황을 알 수 있고, 

백엔드, 디자이너 , QA, 기획자, PM 중 어떤 사람이든 프론트엔드에 관해 궁금한 사항이 생기면 현재 개발 상황을 보고 더 자세하게 파악하여 질문 할 수 있다고 생각한다.

4. 좋았던 점과 개선할 점

전체적으로 내가 느꼈던 점을 기록한다.

4.1. 좋았던 점

• 모든 인원들이 적극적으로 나서주어서 좋았다.
• 회의도 자주 가지며 서로의 생각을 맞춰나가는 과정이 좋다.
• 모바일 뷰를 메인으로 하는 프로젝트는 처음이라 고려할 부분이 많을 것 같아 기대된다.
• 실제 현업자 분들과 함께하는 프로젝트라 그런지 몰라도 더 짜임새있는 기획과 정책을 맞춰야하고 고려할 게 많은 개발이 꽤 재미있다.

4.2. 개선할 점

• 정책이 피그마에 작성되어 있는지 몰라서 뒤늦게 발견했다. (한 2주정도 늦었다, 이 경우 바로바로 질문했으면 바로 알았을텐데)
  • 덕분에 기능 개발이 늦어졌고, 현재 세부적인 개발 상황이 아쉽다. 
  • 합류한지 얼마 안되었는데 모르는게 당연하니 질문을 당당하게 해야겠다.
• React Query를 잘 사용하고 싶다.
  • 서버 상태를 아주 우아하게 다루는 React Query의 중요성을 계속해서 느끼는 중이다.
  • React 웹 서비스를 개발하면서 상태를 크게 3가지로 서버 상태, 로컬 상태, 전역 상태로 나눌 수 있는데, 이 중에 서버상태가 가장 중요하다고 느낀다.
  • 즉 네트워크 통신으로 인한 비동기 처리, 에러처리, 동기화 등을 잘하기 위해 React Query의 개념과 기능을 공부하며 적극 활용해보고있다.
• 크로스 브라우징
  
  • "모바일 뷰" 라는건 휴대폰이 타켓인 웹 서비스라는 의미이다.
  • 안드로이드, 아이폰이 대부분인 현 상황에서 각 휴대폰에서 쓰이는 Samsung internet, Chrome, Safari 등 여러 브라우저의 대응이 필요한데, 모바일 뷰 대부분의 경우 chrome에서는 문제가 없다. (chrome으로 개발함)
  • 하지만 safari는 스크롤 시 이유없이 화면이 확대되는 등 이슈가 존재한다.
  • QA 후 문제가 되는 부분들을 빠르게 fix 해야할 것으로 예상된다
• 마감 기한에 쫓기는 개발
  • 1차 스프린트는 급하게 마무리 한 감이 있다.
  • 기능 말고도 컨벤션 재정립, 도메인 공부, 정책 확인 등 자잘한 작업이 많았고, api 명세가 종종 바뀌어 만들었던 기능을 수정하는 작업이 있던 부분이 원인이다.
  • 이제 정비 작업은 끝났고, api 명세는 기능 개발 전 정확히 논의하고 swagger 까지 도입하게 되어 더 빠르게 개발할 수 있을 것으로 기대한다.

5. 마무리 및 여담

5.1. 이제는 빠르게 기능 개발을 해보고싶다

팀 분위기에 적응하고 개발하느라 바빴던 1차 스프린트였다.

기존에 개발하던 습관 중 챙길건 챙기면서, 새로운 시도를 계속 하려고한다.

코로케이션, `react-use`(훅 라이브러리) 같은 라이브러리 활용 등이 그것이다.

우테코에선 위 훅 라이브러리에서 제공하는 것과 같은 모든 기능에 쓰이는 web api를 찾아서 공부하고 적용하며 직접 개발했기 때문에 시간이 꽤 오래걸렸다. 

이젠 어떤 기능에 어떤 web api가 쓰이는지 대충 알고, api의 원리와 공부해야하는 이유(제대로 돌아가는 기능 개발) 등을 어느정도 숙지했으니 적극적으로 오픈 소스를 활용해보고자 한다.

5.2. 개인 공부

최근에는(약 두 달 전 부터) 프론트엔드에서 중요한 언어 / 기술들의 컨셉을 잘 이해하고 사용하고 싶어서 

리액트 공식문서 1회독을 했고, 현재는 React Query 공부 및 정리, 타입스크립트 책 공부를 하고 있다.

실제 코드를 작성하면서 맞딱뜨리는 안티패턴을 개선했고, 기능 개발을 할때 어떤 방향으로 하는 것이 나은지를 느끼는 중이다. 

(staleTime 설정, 서버에서 받아온 상태를 로컬 상태의 초기값으로 넣을 때 고려할 점, interface 들의 union 타입 선언 등)

 

이제 최종 QA 전 마지막 개발 단계인 2차 스프린트로 돌입한다!