-
Notifications
You must be signed in to change notification settings - Fork 5
211104 회의록
HyeonMin Kim edited this page Nov 5, 2021
·
1 revision
현민
- 모든 컴포넌트를 테스트해야하나? 기준이 뭘까?
찬호
- 실시간으로 작업 내용을 수정 및 공유할 때, 클라이언트에서 가지고 있는 정보와 서버에서 가지고 있는 정보를 동기화할 때, 참고할만한 자료가 있는지?
- 다른 자료들은 주로 redis를 사용하여 동기화를 하는데, mysql은 redis보다 느려서 동기화를 할 때, 문제점이 많을지?
인송
Github Issue 만드는 단위- 실시간 서비스를 할 때 Socket 을 이용해서 통신할 지, 아니면 URL Caching 을 통해서 할지...?
- Suspense 를 사용하는게 가능한데, 도입을 해도 되는지 (컴포넌트 레이지 로딩)
- Error Boundary
- 어떤 기술을 고민했고, 이러한 기능을 배웠다.
해수
- 반응형 해야할까...
- Webpack Bundle Analyzer 를 사용해서 번들 사이즈 측정해보기
- 같은 화면을 보고도 다른 동작을 떠올릴 수 있음
- 백로그랑 프로토타입을 상세하게 매칭
- 에픽은 큰 단위 → 에픽 하나가 프로젝트가 될 수 있음
- 태스크 하나하나가 이슈가 되어야 할 듯
- 각 이슈가 어떤 작업을 하는지 명확하게 알 수 있어야함
- ex) 개발환경 설정이지만 하나를 픽해서 등록
- 이슈를 세세하게 세분화하는게 좋을듯함
- 커밋 컨벤션
- as-is:
feat: typeorm 테스트 접속 - to-be:
[#1] feat: typeorm 테스트 접속 - 현업에서 커밋 내역을 열어볼일이 굉장히 많음
- 용호님 팀에서 사용중인 유일한 컨벤션: 무조건 관련 이슈만 태그하기
- 레포가 분리되면 이슈전용 레포를 둘수도 있음
- #번호 로 이슈를 링크하는게 아니라
[boostcamp/issue#1]와 같이 할때도 있으므로 커밋 메시지가 길어지는 경우가 있음 → 깃모지가 이럴때 제목 길이를 줄여주기도 함 - 커밋 컨벤션을 검사하는 훅을 둘수도 있음 → Husky가 검사 / 브랜치 이름에 따라 자동으로 이슈번호를 붙여주는 것도 가능 → 이런 귀찮은 일들을 자동화하는것도 좋은 경험일수도
- 빠르게 개발 시작하는걸 목표로 해봐라 → 그래야 안 지칠 수 있음
- as-is:
- develop 브랜치와 main 브랜치의 차이점이 없음
- 사실상 github flow를 사용하는듯
- 보통 main을 배포하진 않음
- 현업에서는
- develop → release 브랜치를 따서
- release 에서 feature 브랜치를 땀
- release 브랜치에서 날짜를 두고 release 브랜치를 배포
- 거기서 hotfix 가 되고 완전한 상황이 되면 main으로 합침
- 훗날 만들 feature는 따로 따서 작업
- main은 아무튼 무슨 일이 있어도 에러가 나지 않는 브랜치여야 함
- travis CI 대신 github actions 을 쓰는것을 추천
- 훨씬 간편하고 구축하는데 힘이 덜들어감
- 용호님 팀에서는 Jenkins를 사용 → 조금 무거워서 관리를 해줘야함
- 보통 소켓을 많이 사용
- MongoDB / Firebase 에서는 realtime 을 지원하기때문에 고려할 수 있음
- 소켓 이벤트 트리거 → 관련 api를 재요청 할 수 있도록
- 변한 데이터를 모두 보내기 vs 변했다는 것만 알려주기
- 이벤트로 주고받을때 데이터의 정확성을 100% 유지하기 어려워보임
- 컴포넌트 로딩을 suspense에 위임하는 느낌
- 로직을 분리할 수 있어서 활용하면 좋음
- 새로운 키워드: error boundary
- 빠르게 변화가 발생할 때 둘 사이의 동기화를 어떻게 해줘야할까
- 소켓으로 데이터가 왔다갔다 → 동기화가 필요 → 동기화 완료 이전에 제 3자가 다시 요청을 보냄 → 데이터베이스에서 데이터를 읽어 보내줄건데 → 그럼 데이터가 100% 정확한가
- 소켓에서 이벤트 broadcasting 하는 방식으로 동기화를 일일히 체크할 필요 없이 event-driven으로 하면 되지 않을까
- 모든 컴포넌트들을 테스트할 필요는 없다.
- 어디까지 테스트해야하나 → 텍스트가 잘 렌더링되는가?는 우리가 테스트를 해야하는 부분인가를 고민해볼것
- 텍스트를 잘 넘겼으면 잘 되어야하는데.. 과연 실용적이고 의미있는 테스트인가
- 단순한 영역까지 테스트를 해야하는가는 고민이 되는 문제
- 테스트를 하려면 컴포넌트가 작아야함
- 단순 렌더링만 담당한다면 굳이 테스트할 필요x
- 복잡성을 지니는 컴포넌트 (ex input 컴포넌트, form 컴포넌트, 이런저런 케이스가 있어서 달라질때마다 손으로 확인하기 어려운 경우)는 테스트를 해야 한다
- 리액트에서 담당하는 렌더링보다는 우리가 작성하는 로직을 테스트해야한다
- 리액트는 UI 라이브러리, UI 를 렌더링하는 건 거기까지고 store 같은 영역의 로직을 테스트하는게 옳다
- 컴포넌트를 가지고 테스트하는거면 함수 테스트보다 시간도 걸리고 비용도 커서 hook이나 store에서 테스트하는것이 좋을 수도
- 컴포넌트 테스트까진 많이 필요하지 않을 수 있다
- 필요하다고 생각되는건 e2e 테스트 (사용자 입장에서 검증)
- 시간이 된다면 다 테스트 해보는게 베스트 (snapshot test: 코드를 형상화, 이전 코드와 현재 코드를 비교)
- 테스트가 언제 유효하겠다 라고 느껴보는 것도 좋은 경험일 수 있음
- props를 넘기면 당연히 렌더링이 되어야 하는데, 렌더링이 되는지까지 테스트하는것이 과연 효율적인가.
- 컴포넌트는 ui만 담당하도록 하는 것이 좋다.
- 바쁜 조직이면 테스트를 못하기도 함
- 회원 정보가 예시
- 모든 상태를 전역으로 관리하심
- 도메인이 금융 → 모든 페이지에서 접근할 일이 많음
- 로컬스토어를 쓰는 경우도 있는데 딱 이 페이지에서 쓰고 말 데이터, 서버와 통신이 필요한 정보들이 해당
- 어떤것을 전역으로 관리할까x 어떤것을 로컬로 관리할까o
- 상태관리 라이브러리를 사용하지 않는다면 로컬 스토어 관리를 잘 생각해야
- 사이드 이펙트가 발생할수 있음
- HyupUp 프로젝트에서는 상태를 페이지별로 관리하다 끌어올리는 방법이 잘 맞을 수 있음
- Recoil도 Provider를 가지며 상태를 전역적으로 들고있음
- 자기가 가고싶은 회사의 면접을 보기전에 죄송하지만 연습용 회사에 면접을 보는것도 좋은 방법임
- 부캠 전에 면접을 한번 경험해보는것도 좋음
- 면접은 해봐야 알고 늘어남
- 네이버파이낸셜은 기본에 충실하신 분을 원함
- 요즘은 모바일 퍼스트로 많이 함
- 우리는 오히려 PC에 가까운 서비스라
- 굳이 안해도 되지 않을까? 지만 반응형.. 그렇게 안 어렵지 않나..
- 반응형을 하면 디자인을 또 해야되는게 힘듦
- 하나만 갖고가도 충분함
- 시연/접속도 데스크탑으로 하니깐..
-
화면을 넓혀주세요가이드 제공도 괜찮음
- 프로젝트 이름
- 프로젝트 간략하게 한줄
- 어떤 기술을 썼는지
- 몇명이서, 기간 적고
- 내용을 좀 자세히 적으심
- 이 프로젝트에서 어떤 기술들을 고민했고 어떤 문제점을 고민했고 어떤 것들을 배웠다
- 프로젝트는 내가 뭘 할 수 있는지, 적기 위해 존재하는 조연 느낌
- 주연은 내가 뭘 배웠는지
- 신입때는 많이하면 좋은데
- 이력서는 전략적으로 써야함
- 내가 이끌어나가고 싶은 방향으로 적어야함
- ex) 어떤 프로젝트는 인프라에 치중된 프로젝트가 있다 → 근데 이걸 좋아하시는 분들이 면접관으로 오면 그거만 물어보심 → 이런경우엔 빼는게 좋을수도
- 이력서에는 자신있는 것만 적으면 좋다
- 코테 난이도는 사실 다 비슷비슷하다
- 네이버 본사에 가신 분들 → 코테때문에 떨어졌다는 경우는 x
- 작년에는 부캠에서 비교적 많이 전환이 안됐다 → 이번 기수한테는 기회가 아닐까
- 코테도 꾸준히 보는게 좋음
- 안갈거지만 코테만 봐도 좋음 → "실전감각"
- 초반에 너무 달리면 지치니깐..
디자인 시스템, 프로토타입
웹팩, 바벨
CI