- 현업에서도 storybook을 많이 사용하는지 궁금합니다!
- storybook과 같은 팀에 시스템이나 도구를 도입하는 것도 기술적인 도전이라고 말할 수 있나요?
- 디자인도 팀 프로젝트 하면서 해야할 텐데 어디서부터 시작해야할 지 감이 오지 않습니다. 적절한 템플릿들을 가져와서 같이 수정하는 방식으로 진행해야 할까요? UI 관련 일을 어떻게 분담해야 할 지 잘 모르겠습니다.
- figma 사용하자.
- 디자인 템플릿을 찾아야 한다. chakra, mui 써도 된다.
- 다 같이 하는게 좋은데, 의견이 많으면 산으로 가기 쉽다...
- 회의 전에 주제를 주고, 자신의 의견을 준비하라고 한 후 모두의 의견을 말하고 취합하는 것을 회의 시간에 진행하는 게 좋다.
- 화면 구성을 어떻게 구성하는 게 좋은데 어떻게 생각하시는지 ~~~ 라고 미리 말해주고 의견 취합만.
- 적절한 근거를 ㄹ가져와서 제안을 해야한다. (그냥 트집 잡는 듯한 의견은 좋지 않다.) 칭찬도 잘 해주어야 좋다...
- 면접에서 프로젝트에서 가장 큰 기술적 도전을 한게 뭐냐는 질문을 받았을 때 잘 대답이 나오지 않습니다. 간단한 기본 기능을 구현하는 것에 벅차는데 이렇게 기초적인 지식과 능력만 있을때는 어떻게 대답해야 할까요?
- 내 기준에서 큰 문제여야 한다. 고민을 많이 했고 해결을 하는 방안을 고민을 많이 한 부분.
- 도구 도입은 아님. 팀 전반적인 의견을 모으거나, 기술적으로 이견이 있거나, 성능적인 문제거나, 웹 사이트를 상요하기 힘든 부분이 있거나, ...
- 내가 이 문제를 해결하기 위해 어떻게 기획 했고, 어떻게 해결했는지....
- 면접에서는 실패 사례를 이야기 하면 안된다. 이렇게 저렇게 해서 해결해서 개발했던 좋은 경험이었따. 라고 결론이 나야한다.
- 성능이 좋았다. 는 중요하지 않다. 이런 문제점이 있고 어떻게 학습을 했고, 현재의 기술적인 해결책들이 있기 때문에 그것을 잘 봐야 한다...
- ts -> 라이브러리 코드를 까 보는 경험이 있었고,,,, 타입이 없는 라이브러리를 사용 하는 것에도 어려움이 없어졌따.........
- 기술적인 도전은 흐름을 잘 말해주면 된다.
- 프로젝트 하면 매일 매일이 기술적인 도전일 것이다.
- 이력서에서는 성공적으로 프로젝트를 완수하고, 어려운 것들을 잘 완수한 것들을 잘 적어주어야 한다...
- 매일 잘 고민해보고, 한 발자국 더 나아가서 생각해보는 연습을 하자. 다들 잘 하고 있는 것 같다.
- 테스트 코드를 작성할때 반복되더라도 명시적으로 작성하는게 좋다는 의견과 반복되는 부분은 util로 빼자는 의견이 있는 거로 아는데 이에 대해 멘토님의 생각이 궁금합니다.
- RTL (React Test Library)
- 실제 사용자가 사용하는 환경에서 테스트 하는게 좋다. (JSDOM)
- 환경에서 렌더링 환경을 만들고 테스트...
- 모킹은 많으면 좋지 않다... 모킹을 줄여야 한다. 모킹이 많으면 비용이 는다. 실제 화면이 아니라서(?)
- 스냅샷 테스트는 좋지 않다. 눈으로 봐야하는 테스트라서. DOM을 사진 찍듯이 뽑아준다. DOM의 결과가 저장된다.
- DOM이 많이 변경되는 환경에서는 의미가 없다.
- 쿼리에도 우선순위가 있따. 공식 문서에 해당 내용이 나와있다.
기획이 먼저 나와야 한다.
기획을 최대한 빨리 구체화 하고 화면 구성까지 가면 디자인은 오래 안걸릴거라 생각한다.
구현을 하는 게 목표이기 때문에, 길어도 2-3일 내에는 디자인을 끝내는 게 바람직하다.
빨리 마무리하고 개발하는 게 낫다. 개발하고 빨리 배포하고 추가 기능 구현하는 게 좋을 것이다.
협업 도구 왜 쓰는지가 중요하다. 뭘 쓰는지는 안중요하다. 히스토리를 한 곳에 모아 두도록 하자...