피그마(최종 디자인)
문서
깃허브
질문
- 현재 프론트엔드와 백엔드가 jira를 같이 사용하고 있는데, 서비스 도메인 별로 도메인을 나누었더니, 프론트엔드만의 영역과 백엔드만의 영역이 커버가 안되서, 각각 프론트엔드 에픽과 백엔드만의 에픽이 따로 존재하는 상태입니다. 해당 부분을 어떤식으로 처리하나요?
Jira
위에 노션 노드가 수정이 안되서..
밑에 복붙합니다 (
)
)현재 프론트엔드와 백엔드가 jira를 같이 사용하고 있는데, 서비스 도메인 별로 도메인을 나누었더니, 프론트엔드만의 영역과 백엔드만의 영역이 커버가 안되서, 각각 프론트엔드 에픽과 백엔드만의 에픽이 따로 존재하는 상태입니다. 해당 부분을 어떤식으로 처리하나요?
- 질문이 정확히 이해는 안되는데요, “프론트엔드만의 영역과 벡엔드만의 영역”이라는 말씀은, → 기능 구현 이외에 프론트만 하는 작업들, 백앤드만 하는 작업들을 말씀하시는 걸까요?
- 맞다면, 현재의 구조로 잘 나누셨다고 생각합니다. 네이밍만 좀더 구체적으로 “기능 개발 외 작업"으로 만드시는 것도 괜찮으실꺼같아요.
- 실무에서도 기능개발이외의 작업을 따로 백로그나, 기능개발외 작업 이라는 네이밍으로 만들고 그 안에서 작업 티켓들을 생성합니다. 작업 티켓들에서 포지션을 구분하기위해 티켓에 prefix를 쓰곤 하는데요
[WEB] ~~~,[Server] ~~~, 방법은 여러가지입니다. - prefix로 티켓 title에서 네이밍 구문
- 지라의 component이나 라벨 기능을 활용하여 구분
기타
👍 스토리 → task로 작업을 쪼개셨던 부분 좋습니다! 유저 스토리 기반으로 하셨는지 궁금하네요 ~ 우리맵(Woorimap)
- ❓ 잡으신 스토리 포인트는 달성도가 몇프로라고 각자 생각하시나요?
tip) 이슈연결도 잘 활용하시면, 로드맵에서 적절히 시각화가 됩니다.
- e.g.
is blocked by,blocks: 특정 작업에 해당 작업이 블로킹이되거나, 블록이되어서 작업이 되지 않을 경우 해당 타입으로 이슈를 연결해두면, 작업끼리 관계가 시각화가되어서 가시화에 좋습니다.
Atomic Design 을 잘 활용하고있는지 궁금합니다.
- 준비 단계에서 산출한 컴포넌트들은 어디에 정리하는지도 궁금합니다.
- 질문이 잘 이해가 안되네요 ㅠ 구현한 컴포넌트들을 어떤 directory에 두는지가 궁금하신걸까요?
- (뱅크샐러드 규칙기준) 디렉토리의 root에는 공용컴포넌트, 도메인별로의 컴포넌트는 도메인 하위에 두곤 합니다.
- 요건 각 조직별로 규칙 잡기에 따라 달라지므로, 정답은 없습니다!
source of truth- atom 크기(정확히는 버튼입니다)임에도 불구하고 도메인에 강하게 묶여있어서, 재사용 가능성이 적은 컴포넌트들은 어디에 배치하면 좋을까요?
- molecule이나 organism에 두시면됩니다.(둘 중 어디둘지는 팀내 규칙에 따라) atom은 pure한 태그수준만 둔다고 생각하시면 됩니다.
- e.g. 이미지를 업로드하는 버튼 [ 이미지 업로드 ] → molecule
기타
- 재사용 측면에서 atomic 구조 도입은 좋습니다 👍 다만 현재 구조를 보니, 기준이 조금 흐트러지고 있는 듯 한데요, 정돈하면서 진행하기에 리소스가 부족하시다면, 추후 각 단계별로 기준을 잡으셔서 규칙으로([필독] 프론트 엔드 기술 스택 & 컨벤션) 만드시고 리팩토링을 해주셔도 좋을 듯 합니다.
페이지 디자인 중에서 눈에 띄는 개선점이 있는지 궁금합니다.
- 컴포넌트의 크기와 배치 등
- 디자인 피드백이 될거같아서, 가독성만 보자면, 전체적으로 균형이 흐트러진 부분은 없는 듯 합니다!
- 인터렉티브 스타일 대응을 좀더 하시면 디테일이 챙겨질 것 같습니다.
- 컴포넌트 별로 (atom기준): disabled, focus, hover, …
- 이미지가 화면에 로드될때까지 로더가 보인다.
- 첫번째가 삭제되면, XX된다.
- 중간이 삭제되면 삭제된 이미지가 사라지고, 뒤의 이미지가 slide된다.
- ….
각 컴포넌트 사용성 ⭐
e.g. 이미지 리스트
이미지가 삭제될 경우,
실제 업무에는 Figma에 어떤 내용이 있는지 궁금합니다!
기본적으로 flow기준으로 정리되어있습니다.
- 유저 스토리별 → 성공 flow + 엣지 flow (상태별 상황, 에러 상황들, …)
- 컴포넌트 → 다만 컴포넌트 정리는 다른 프로젝트로 처리되며, 피그마의 컴포넌트 기능을 이용해서 프로젝트별로 이를 활용합니다.
일반적으로 로그인 관련해서 인증 처리를 어떻게 하나요?
- 현재 로직은 다음과 같습니다. (Next.js를 사용함에도 불구하고 SSR 개념을 잘 몰라서 일단 클라이언트 사이드에서 인증을 처리하고 있습니다.)
- 로그인을 하면, 서버로부터 refresh token을 쿠키로, access token을 body로 받습니다.
- access token을 로컬 스토리지에 저장합니다. (해당 부분 로컬 스토리지에 저장하는 것이 맞는 방법인가요?)
- access token이 만료되면 refresh cookie를 통해 access token을 갱신합니다.
답변
- 해당 부분 로컬 스토리지에 저장하는 것이 맞는 방법인가요?
- 맞는 방법은 없습니다. 상황에 따라 하나의 방법으로도 쓰입니다. 로컬에 저장하는 이유는 브라우저를 종료하더라도 로그인을 유지하기 위해서 종종 쓰입니다.
- 브라우저 쿠키를 활용해서 일정 기간 이후 재로그인을 유도하거나, 세션을 활용해서 브라우저 세션때만 토큰을 활용하도록 하기도합니다.
이미지 캐싱 처리
- 현재 디테일 페이지에서 각 페이지당 많은 이미지를 불러 와야 하는데, 이를 캐싱을 통해 변경되지 않은 리소스이면 불러오지 않는 캐싱 처리를 해보고 싶습니다! 이러한 처리를 “프론트앤드”에서 해결 할 수 있는 방법이 있는지 궁금합니다!
- 캐싱은 service worker을 활용해보시면 좋을 듯 합니다.
- service worker: 리소스 브라우저에서 캐싱
- 기타: 캐싱 이전에 lazy load도 해보셔도 좋을 듯 합니다.
- prefetch: 리소스를 사전에 fetching하는 방법
- intersection obervable을 활용한 레이지 로드
추가적으로, 이 부분을 보완했으면 좋을 것 같은 부분이 있나요?
우선순위
p1: 꼭 하세요
p2: 꼭 하시면 좋겠어요
p3: 하시면 좋겠어요
p4: 문제는 없지만 제안합니다.
p5: 시간될때 하면 좋고, 안해도 무관!
- 문서화
p1(나중에 하실것 같지만!) 리드미 정리
- 안정성
p3utils 파일 → 테스트 코드화p5체험형으로 msw라는 api mocking 모듈도 써보셔도 좋을 것 같습니다
- 디테일
p2디테일 챙기기 컴포넌트쪽에 말씀드렸던 인터렉션 구현p3유저 스토리 내에, 엣지케이스 챙기기
- 기타
p4부채라고 생각되거나 리팩토링 해야하는 부분들도 서서히 리스트업해두셔도 좋을 듯 합니다. (혹은 주석에TODO:로 작성)p5컨텍스트가 많은 부분에는 주석을 달아보셔도 좋을 듯 합니다. (vscode extension)- “컨텍스트가 많다" == 다른 사람이 이해하기에 코드만 보고 이해하기 힘듯 부분 (상황설명이 필요한 부분)