<협업 회고>
어려웠던 점과 문제점
1. Node 버전 문제
- 설명
- 각 Node버전이 일치시키지 않은 상태로 프로젝트를 시작. 불특정 시점에서 npm install를 하면 package-lock.json 파일이 일치하지 않아 컨플릭트가 빈번하게 발생하는 문제에 직면 (Node v14, v16)나름의 해결책
- mac M1 이슈로 인해 Node LTS v14가 아닌, v16.10.0으로 일치하여 위 문제를 해결함.
2. 브라우저& 모바일 기획
- 설명
- 초반에 브라우저 기반으로 UI를 기획하고 모바일 버전에서는 반응형으로 사이즈 줄이면 되겠지라는 막연한 생각으로 기획을 함.
- 이로 인해 모바일 버전이 되었을 때 없어지는 nav들의 경우 어디에 두어야할지 막막한 상황이 생김
- 나름의 해결책
- 최대한 컴포넌트를 재사용하는 쪽으로 기획을 변경함
- 기존에 오른쪽 사이드에 존재하던 NavSocial(친구 추가)을 헤더의 메뉴로 추가함으로써 공간 확보
- 친구 추가 클릭 시 기존에 웹에 존재하던 모달을 모바일에도 재사용
- 왼쪽 사이드 NavChannel(질문)의 경우 모바일 버전에서는 버튼을 이용하여 열고 닫기가 가능하게 기획 수정
- 기존 웹에서의 NavChannel을 재사용하여 토글 형식으로만 변경, 사용자는 메인 컨텐츠에 더 집중할 수 있게 됨
3. 이슈 기반 협업 관련
- 설명
- MainPage, IntroPage 구현시 각각 페이지에서 사용되는 컴포넌트의 수정사항이 빈번하게 발생함
- 컴포넌트의 변경된 상황을 하나하나 이슈로 등록하여 개별적으로 수정하고 커밋을 남기는게 올바르다고 생각하였으나, 이때, 변경된 컴포넌트들은 개발자마다 중복, 동시에 수정한 컴포넌트가 없었고, 개발 속도에 우선순위를 두어, develop 브랜치로 각자 작업 내용을 커밋 & 머지를 진행함.
- 나름의 해결책
- 위와 동일하게 중복, 동시에 수정한 컴포넌트가 없었기 때문에 각자 작업 내용을 커밋 & 머지를 진행함
<기술 회고>
어려웠던 점과 문제점
1. 회원가입 페이지 기능 개발 시, 자식 컴포넌트(form)에서 조상 컴포넌트(page)로의 데이터 전달
- 설명
- [회원가입 페이지] - [Modal] - [회원가입 Form] 의 컴포넌트 구조로 설계를 하였음
- 회원가입 Form의 submit 버튼을 누르면, Form 에서 작성한 데이터가 API 로직을 타고 서버로 넘어가야 하는 상황
- API 통신 함수는 현재 Page 컴포넌트에 작성이 되어 있음
- 하위 컴포넌트의 데이터를 가지고 와서 Page 컴포넌트에서 정의된 API 통신 함수를 실행하고 싶었음
- Props로 하위 컴포넌트에 데이터를 넘기는 방법은 알고 있었지만, 역으로 데이터를 올려주는 방법은 모르고 있던 상태
- 나름의 해결책
- 부모의 value가 아닌 함수 자체를 props로 목적지 하위 컴포넌트에 넘겨주고, 목적지 하위 컴포넌트에서 하위 컴포넌트의 value로 전달된 함수를 실행해주었음
- 수직적 컴포넌트 관계에서는 이러한 방식으로 데이터를 전달할 수 있지만, 부모-자식 간 거리가 멀다면 비효율적인 방법이라는 생각이 들었음
2. 전역 폰트 설정
- 설명
- Create-react-app 환경에서 한글/영어에 따른 전역 폰트 설정 방법
- Index.html에서 처럼 CDN을 입력하여 사용하는 방법이 아닌 애플리케이션 내에 폰트를 저장하여 사용하고자 함
- 검색된 내용마다 방법이 달라 무엇을 적용해야 하는지 혼선이 있었음
- 나름의 해결책
- fonts 폴더에 구글 폰트를 압축하여 용량을 줄인 파일을 넣고, index.css 내에서 font-face 설정을 찾아 적용함 현재 폰트는 잘 적용된 것으로 보이나 간혼 input 내에 적용되지 않는 현상이 보이기도 함
<질문거리들>
1. base component style 관련
도메인에 컴포넌트를 만들 때 base component(input, button 등)를 import하여 사용하는 중입니다.
현재 base component의 경우 default 값으로 (페이지 개발 시 쓰일)스타일이 완벽히 적용되어있지않고, 속성 값의 경우에도 기본적인 props만 받고 있습니다.
이런 상태에서 도메인 컴포넌트 개발 시 스타일드 컴포넌트 또는 인라인 스타일로 스타일을 다시 적용해야하는 상황들이 빈번하게 발생합니다. 코드가 매우 길어지고 지저분해보입니다.
현업에서 base component를 만들어 사용하실 때 완벽하게 스타일을 잡아서 만드시는지 궁금합니다
2. API 로직 관련
선협님의 강의에서 컴포넌트는 순수하게 유지하고, 네트워크 로직의 경우 pages에서 작성하면 좋다는 설명을 들었습니다.
pages에서 따로 따로 관리하는 방법, utils에 따로 파일을 만들어 관리하는 방법 등 여러 방법이 존재할 것이라 생각합니다.
팀마다 사람마다 API 로직을 관리하는 방식은 다양하겠지만, 어떤 방법을 선택하는 것이 좋을지, 현업에서는 주로 어떤 방식을 사용하는지 궁금합니다.
3. 개발 속도가 다른 팀원과의 협업 시
현재 저희 팀은 각자의 개발속도에 차이가 있습니다. 업무의 분배는 동일한 편이라고 생각합니다. 각자 베이스 컴포넌트, 훅과 페이지를 분배하여 프로젝트를 진행하고 있습니다.
다만 문제는 개발 속도가 상대적으로 느린 팀원이 개발하고 있는 컴포넌트(A)를 개발 속도가 빠른 팀원의 다른 컴포넌트(B)에서 필요로 할 때입니다.
저희는 개발 속도가 빠른 팀원이 일단 개발이 완료되지 않은 컴포넌트(A) 대신 임의로 데모로 작성하여 기능(B)을 개발하는 방식을 선택했습니다.
시간이 조금 흘러 A가 완성된 경우, 데모 컴포넌트로 개발이 되고 있던 B 컴포넌트도 이슈를 생성하여 수정을 해야 하는지 궁금합니다.
현업에서는 베이스 컴포넌트, 훅, 페이지에 대한 분배를 각각 하여 개발을 하는지, 아니라면 어떻게 개발 업무를 분배하여 협업을 하고 있는지 궁금합니다.