요약: 큰 그림 → 작은 그림
1. base component style 관련
도메인에 컴포넌트를 만들 때 base component(input, button 등)를 import하여 사용하는 중입니다.
현재 base component의 경우 default 값으로 (페이지 개발 시 쓰일)스타일이 완벽히 적용되어있지않고, 속성 값의 경우에도 기본적인 props만 받고 있습니다.
이런 상태에서 도메인 컴포넌트 개발 시 스타일드 컴포넌트 또는 인라인 스타일로 스타일을 다시 적용해야하는 상황들이 빈번하게 발생합니다. 코드가 매우 길어지고 지저분해보입니다.
현업에서 base component를 만들어 사용하실 때 완벽하게 스타일을 잡아서 만드시는지 궁금합니다
멘토님의 답변:
통일성을 위해 스타일은 고정해놓는것이국룰이다. 프롭스로 스타일을 너무 확장성있게 주면 안된다.
와이어프레임을 쓰는 이유가 있다. 와어프레임 위에 그려놔야, 어떤 버튼 리스트가 있는지 확인할 수 있다.
좋은 디자이너가 있는 회사에서는 figma에서 한 depth가 더 들어간다.
- 버튼에 대한 종류별로 figma 를 정해준다.
처음부터 CSS에 하나하나 신경을 쓰면 머리가 아프다
기능개발이 안되어있는 상태에서 CSS부터 만들면, 머리 깨진다.
어떤 식으로 동작을 하게 할 것이냐. handleChange, value 등의 props에만 집중해서 이제 개발하고, 기능 개발이 어느 정도 진행되면 css작업을 한다.
물론 사이즈가 어느 정도 정해져 있긴 해야된다.
"버튼을 만들건데.. 그려진건 없어요..."이러면 안된다.
base컴포넌트를 제일 조심해야되는 요소!
- 페이지마다의 요청사항이 다르다.
- 요청사항에 맞춰서 base컴포넌트를 만들면
- base컴포넌트의 초기 컨셉이 엉망이 된다.
- 따라서, base컴포넌트의 컨셉을 확실하게 정하고, page를 해당 컴포넌트에 맞추는 게 낫다. (바텀→탑)
2. API 로직 관련
선협님의 강의에서 컴포넌트는 순수하게 유지하고, 네트워크 로직의 경우 pages에서 작성하면 좋다는 설명을 들었습니다.
pages에서 따로 따로 관리하는 방법, utils에 따로 파일을 만들어 관리하는 방법 등 여러 방법이 존재할 것이라 생각합니다.
팀마다 사람마다 API 로직을 관리하는 방식은 다양하겠지만, 어떤 방법을 선택하는 것이 좋을지, 현업에서는 주로 어떤 방식을 사용하는지 궁금합니다.
멘토님의 답변:
컴포넌트마다 axio에서 바로바로 받아서 API를 사용하는 방법은 추천하지 않는다.
- baseUrl사용
- 400대 , 500대 에러 등에 대해서 공통적인 에러사항들에 대해서 공통적인 코드가 들어가게되곘네?
- API 파일을 별도로 만들어서, 로직을 별도로 빼서 사용 (API.js)
.env(baseUrl) 이 무조건 있어야 한다!
별도의 파일을 빼서 api를 만드는거다.
처음부터 완벽한 props가 존재하는 컴포넌트는 존재하지 않아요.
그렇지만 page를 만들면서 공통적으로 발생되는 사항을 컴포넌트로 만들어서 -> 재사용하고,
공통 이슈가 발생하면 컴포넌트로 만들면서 점차 완성도를 높이는 것.
처음부터 설계, 기획단계에서 완벽한 컴포넌트는 없다.
비슷한 컴포넌트라도, 프로젝트의 성격에 따라 달라질 수 있다.
3. 개발 속도가 다른 팀원과의 협업 시
현재 저희 팀은 각자의 개발속도에 차이가 있습니다. 업무의 분배는 동일한 편이라고 생각합니다. 각자 베이스 컴포넌트, 훅과 페이지를 분배하여 프로젝트를 진행하고 있습니다.
다만 문제는 개발 속도가 상대적으로 느린 팀원이 개발하고 있는 컴포넌트(A)를 개발 속도가 빠른 팀원의 다른 컴포넌트(B)에서 필요로 할 때입니다.
저희는 개발 속도가 빠른 팀원이 일단 개발이 완료되지 않은 컴포넌트(A) 대신 임의로 데모로 작성하여 기능(B)을 개발하는 방식을 선택했습니다.
시간이 조금 흘러 A가 완성된 경우, 데모 컴포넌트로 개발이 되고 있던 B 컴포넌트도 이슈를 생성하여 수정을 해야 하는지 궁금합니다.
현업에서는 베이스 컴포넌트, 훅, 페이지에 대한 분배를 각각 하여 개발을 하는지, 아니라면 어떻게 개발 업무를 분배하여 협업을 하고 있는지 궁금합니다.
멘토님의 답변:
지금 여러분들 수준에서 동료의 개발속도를 가늠하는게 쉽지 않다.
하지만, 협업에서는 기능을 언제까지 개발할 수 있는지 대략적으로 파악하는 능력을 배양하는게 중요하다. 그래야 개발일정을 산출해 낼 수 있는 것이기 때문. 그리고 그 결과에 따라서, 현재의 개발속도가 어느 정도인지를 파악할 수 있고, 결과적으로 전반적인 개발계획을 유동적으로 수립해 나갈 수 있다.
업무의 분배 관련 :
공통컴포넌트(만 만드는 팀이 존재) / 페이지(만 만드는 팀이 존재)할 수 있다.
==
프레임워크(를 만드는 팀이 존재) / 페이지에서 필요한 기능(만 만드는 팀이 존재)할 수 있다는 것.
(여러가지 버튼, 라디오, 인풋) 등을 전담해서 개발하는 팀이 개발하고(프레임워크) 패키지화 할 수 있다.
4. 개발 속도와 기능의 중요성
중요도가 높지만 개발 하는데 시간이 오래걸리는 기능과 중요도가 높지 않지만 진전속도가 빠른 기능 중 무엇을 우선순위로 두어야할까요??
멘토님의 답변:
중요도가 높은 것부터 개발하는게 맞다!
5. 디자인팀과 소통툴
storybook은 다른 환경에 영향을 받지않고 특정 컴포넌트를 개발하는 장점외에도 특정 컴포넌트의 UI를 한번에 파악가능하고 테스트를 하기 용이하다고 생각합니다. 그런면에서 UI를 빠르게 구현하고 디자이너와 소통하면서 수정이 가능하다고 생각하는데 현업에서도 이러한 툴을 디자인팀과 소통툴로 사용하는지 궁금합니다.
멘토님의 답변:
스토리북을 잘 쓸 때의 장점이다.
Figma(디자이너의 영역) vs Storybook(개발자의 영역) - 서로가 같은 생각을 하며 업무가 진행되고 있음을 확인할 수 있다. 스토리북을 통해서 디자이너, PM과 더 원활한 협업을 이룰 수 있다.
6. README 작성
개발이 모두 완료된 후에 README를 적곤 했는데 프로젝트 시작전에 해야하는 일일까요?
보통 프로젝트 README에는 어떤 내용을 적어야하고, github 주소를 이력서에 제출하거나 포트폴리오에 썼을때README에서 중점적으로 보는 부분은 어떤 것인지 궁금합니다.
멘토님의 답변:
미리 적어라.
README.md 에 기술하기에는 너무 많은 내용이 존재한다면, 별도의 문서 파일을 작성하고 링크를 걸어줄 수도 있다. ex) 설정.mdREADME.md 를 잘 적어야 면접에서 좋은 인상을 심어줄 수 있다!- 면접 회사에서 지원자의 개발 소스를 볼 텐데,
README.md는 지원자 프로젝트의 첫인상이라고 할 수 있다.README.md가 잘 작성이되어있지 않으면, 소스조차 보지 않는다.
7. 개발단계에서의 프로세스 순서
레이아웃, 기능개발, 상세 style 개발등, 개발단계에서도 각각의 세부단계들이 있다고 생각합니다.
처음 프로젝트를 진행하다보니, 개발단계에 들어선 다음부터 프로젝트가 정돈되지 않은채 흘러간다는 느낌을 받고있습니다. 그러다보니 현재 우리가 어느 단계에 있고, 무엇을 해야할지 갈피를 잡는데 시간이 오래걸리게 되는것 같아요.
멘토님께서 추천해주시는 개발 단계에서의 프로세스 진행방식이 있을까요?
멘토님의 답변:???
와이어프레임을 통해서 개발하지는 않는다.
DND의 Case:
어떤 프레임워크/라이브러리 선택→세팅→레이아웃(page, component...)→와이어프레임 슥 보기
→router로 빈 페이지 만들어놓기 → 페이지 별 공통요소를 뽑아내기 → 뽑아낸 공통요소를 컴포넌트로 만들기 → title,description 에 따라서 img를 처리해준다. → container의 width 값을 정해보기 (dnd의 경우 1440px) → 각 페이지마다 width를 1440으로 잡고 개발을 시작했다. → 즉, 큰 요소들부터 하나하나 잡아갔다.
막~ 처음부터 세세한 디자인을 생각하며 개발하지는 않았다. 중요한건 기능개발! 기능개발 이후 CSS → 배포
그리드의 경우, 일단 그리드로 크게크게 뿌리고, 이후 텍스트와 이미지의 위치를 잡고, 페이지네이션 로직을 도입했다.
하지만 명심해라, 개발 프로세스는 팀 규모별로, 조직 별로 다르다.
기동님은 웹/모바일 중, 웹부터 개발하고 나서 줄였을 경우에 대해 개발을 한다.
8. CSS
디자인까지 하다보니 정확한 사이즈를 측정하기가 쉽지 않은데 보통은 디자이너가 반응형까지 고려한 px 사이즈를 전달해주나요?
멘토님의 답변:
그렇다. 디자이너가 있으면 웬만하면 다 해준다.그렇지 않을 경우에는....?
rem 을 활용하자. 보통 1rem ~~=16px. 1rem ⇒ 16px → 14.5px 처럼 현재 사이즈에 맞춰 폰트 사이즈가 조정이 된다.
9. Gravatar → 사용자 계정에 등록된 이메일 이미지를 가져올 수 있는 라이브러리. 만약 계정이 없다면, 랜덤 이미지를 가져올 수 있는 라이브러리
자... 여기를 좀 봐주세요^^
끝~