질문1
서로가 blocker가 되지 말자는 멘토님의 자문을 듣고 각자 페이지에 필요한 컴포넌트들은 개인적으로 만드는 디렉토리 구조로 협업을 하려고 합니다. 저희 디자인을 보시면 메인페이지의 머쓱이 카드와 프로필 페이지의 머쓱이 카드 페이지들이 겹쳐서 이런 부분들은 각자 개인적으로 만들기 전에 미리 컴포넌트로 빼서 확장성있게 만들어 놓는 것이 좋을까요? (참고로 chakra 컴포넌트 layout을 기반으로 개발하려고 합니다!)
누군가가 공동 컴포넌트를 빠르게 만드는 것도 하나의 방법이다.
대부분 기능 구현은 시간이 많이 걸리지 않도록 한다.
협의에 따라서 기능 구현 위임도 가능하다.
참고. Radix, chakra 2.0
질문2
- 사용자가 머쓱이 이미지의 특정 위치를 클릭하면 그 위치에 장식을 추가하려는 기능이 있는데, 구현 가능성과 관련해서 질문이 있습니다. 위 그림은 참고 디자인 입니다!
- 장식을 설치하려는 특정 좌표는 어떤 방식으로 기억해야 할까요? 마우스 이벤트 객체 정보를 확인하면 어느정도 추측할 수 있을 것 같은데, 화면 해상도마다 좌표가 다를 것 같아서 비율에 대한 보정을 어떻게 해야할지 고민이 있습니다.
- 사용자 여러 명이 같은 위치에 동시에 장식을 설치한 경우에는 겹쳐서 보이기 때문에 예외처리를 해야할 것 같은데, 좋은 방법이 있을까요?
- 단순히 img 태그를 겹쳐서 보여주는 구현 방식도 괜찮을까요? 혹은 반드시 canvas를 사용해야 할까요?
대부분 canvas 기본으로 만든다.
꼭 필요한 기능에( ex. 다른이에게 마음을 전달하는 ) 집중한다. Canvas 부분의 스펙을 다르게 조정해보거나, 후순위로 개발해도 괜찮을 수 있다.
기능 개발의 우선순위를 정하면 좋다.
질문3
편지를 발송하면 수신자에게 슬랙 DM으로 알림을 보내는 기능을 생각 중인데 실현 가능한 부분일까요? 사실 처음에는 카카오톡 알림을 활용하려고 했었는데 메시지 발송마다 비용이 드는 것으로 알게 되어서 슬랙을 활용하려고 합니다.
슬랙 메시지 API 권한 알아보기. (+ Slack API 플레이그라운드 참고)
슬랙이 주체가 되도록 서비스를 생각해보는 것도 좋다.
Hey taco, hey britto(?)…
질문4
기획한 구현 사항을 Postman을 이용하여 API 요청과 응답 테스트를 하지 않은 상태인데, 기능구현하면서 API 테스트를 같이 진행해도 괜찮을까요?
각자 맡은 기능에 대해서 API 테스트를 진행하고 JSON 데이터를 생각해본다. 데이터가 어떻게 내려올 것인지 공통으로 미리 정한다. (+ API 요청은 각자 만들 수 있다)
질문5
저희가 현재 UI를 설계했을 때 로딩이나 에러에 대한 화면은 따로 작성해두지 않았는데, Suspense의 도입이 반드시 필요할까요?
로딩과 에러 대처는 필요하다. 사용자의 이탈률이 나지 않도록 Skeleton Loading을 구현해도 좋고, 기본 로딩을 구현해도 좋다.
ex) 데이터 불러오는중인지 로딩 처리.
질문6
저희 서비스가 재작년 인스타그램 스토리에서 유명했던 “내 트리를 꾸며줘” 서비스에서 벤치마킹한 프로젝트입니다. “내 트리를 꾸며줘” 서비스는 모바일 화면에 친화적인 서비스이다보니 저희 서비스도 모바일 친화적인 UI도 필요한 것은 아닌지 우려가 됩니다. 이미 웹 특화된 디자인이 완성되어서 따로 또 모바일 UI를 준비하는 것이 부담이 되는 것 같습니다. 그대로 웹 특화된 서비스로 가는것이 좋을까요 아니면 반응형 구현을 위한 시간을 필수로 마련하는 것이 좋을까요?
모바일 반응형은 필수 구현사항이다. (First 모바일 중심 개발)
질문 외 내용
Lodash 이용 시, Tree-shaking을 이해하고 이용하면 좋다.
Git Flow의 버저닝 (ver1. Ver2...)보다 기능 구현에 집중한다.
각자 기능 구현사항에 대한 구체화된 계획이 있으면 좋다.
로그인페이지에 Slack 연동이 필요할 수 있다.