3주차 멘토링

멘토링

OaO Design

wireframe 보여드림

TDD

정렬 방식

• side effect가

• 굳이 그 정도로 해야 되나 싶기는 한데

• Array.reduce → Array.every로 수정하는 피드백 주심

  • reduce를 쓰기 전에 some, every 등 고차함수 사용하는 것 추천

• why?

  • 테스트 케이스, 데이터 volume 충분히 많이 확보하기 위함
  • TC를 짤 때 input에 대한 경우의 수를 더 늘리면 좋을 듯
    • 실패를 하는 경우도 추가하면 좋을 것 같다는 의견을 주심

• 조건 검증 코드 짜고, 조건을 검증 코드를 검증하는 코드를 짬 (가루로 된 고기,, 싸서 드셔보셨나요)

  • 그래프 그리면서 검증함 (다른 팀 backlog로 mock data 만듦)

• 대단위 테스트: 정답 shuffle → 정렬 → 다시 정답이 나오는지 검증

CI/CD

🔥 CI CD 적용기 with release 자동화 🔥

• CI

  • codecov 적용

• CD

  • side effect 방지를 위해 docker container 사용
  • Frontend docker
  • Backend docker
  • Nginx proxy docker

  ⇒ docker compose 사용

  • proxy image 매번 다시 올려줘야하는지 내부 검토중

• release 서버 분리

• release 버전 올려주는 것

  • 멘토님 : github PR 만들때 PR tag를 달던지, commit에 달던지 해서 update하는 방식이 있음

여쭤볼거

• DB 선택 : GraphQL 찍먹 해볼래라고 특강에서 들었는데 멘토님께서는 사용해보셨나요..?

  • NoSQL DB는 MongoDB dynamo DB만 사용해봄
  • 여러가지 시도를 해보려고 test code를 짠거다…!

• git rebase

  • 잘 안쓰심
  • 왜 rebase를 쓰게 되었는지?
    • 배민에서 rebase를 사용한다는 글을 봤었음
    • 이력 관리를 깔끔하게 하는 것도 좋은 경험일 것 같았음(merge commit)
  • merge commit과 rebase는 방법론의 차이
  • 개발 branch는 막 다루되, release 같은 부분에서 merge 전략을 어떻게 하는지가 graph 관리에서 중요하다
  • 개발 branch에선 commit을 막 넣되, merge commit으로 release에 넣으면 다 들어가기 때문에 squash merge
  • commit merge와 squash merge의 차이를 알아보는 것을 추천!
  • squash merge하면 원래 merge를 보내려고 하던 branch는 사용 못하지 않는지?
    • merge하니까 그 branch 필요없잖아요!
    • 우리 프로젝트에서 하려면 feature → dev로 할때 squash, dev → release는 일반 merge 하는 게 좋을 듯

• 정렬을 하는 기능이 실제 component나 상태관리에 쓸텐데, 통합적인 기능을 만들고 그 기능에 대한 test를 만드는 것이 좋을텐데…

  • validate라서 명명이 좀…util로 만드는게 좋지 않을까? (원래 js, ts에 validator 라이브러리가 있어서 코드를 봤을 때 혼란스러운듯)
  • ex) 1번이 2번의 상하조건일 때 이렇게 정렬이 되야 한다.
    • abc→cba 이런 결과가 되어야 한다. 이런 식으로 한 눈에 보여줄 수 있도록
    • id 1,2,3,4 → 4,3,2,1이 되어야 한다.
    • description을 좀 더 와닿게 쓰면 좋을 듯
      • 이 함수의 사용 설명서!
      • 이 TC만 보고 이 함수가 무엇을 하는 역할인지 파악 가능하도록 직관적으로 쓰면 좋을 것 같다!

• 시간싸움

  • 회원가입,, 로그인은 뒤로 해보자 (현명하신 판단..)
  • 실제 서비스였다면 db 전환 시 data migration도 했어야 할 듯
  • 화면, todo, 정렬 후에 시간이 남으면 로그인, db 연동
  • 충분히 교체 가능한 것들을 후순위로

• 컴포넌트 분리 기준?

  • 최대한 그 모듈(컴포넌트)이
  • input error message, label 등 조건이 들어가면 비대해짐. 이 때 이름과 역할에서 벗어나면 분리하거나 확장.
    • input은 그대로 두고, 상위에 컴포넌트를 만들기도 한다.
    • atomic 패턴. 가장 작은 요소 → 상위요소에서 atom을 조합해서 만들기
    • 너무 과한 분리로 인해 사용성이 떨어지기도 하지만, 작은 단위로 나누고 조합해서 사용하는 방법 추천
    • 확실하게 그 역할을 수행하게끔!
    • 장점) TDD(테스트)를 할 때 그 모듈만 테스트하면 됨. 종속적인 애들은 이미 검증이 되었다고 가정. 종속적인 애들에 대한 검증은 고려하지 않는다. mocking도 안전하게 할 수 있다!
    • 컴포넌트 테스트 시 역할이 너무 많아지면 비대해지니까 custom hook으로 분리해서 custom hook만 따로 테스트. 테스트 시에는 custom hook만 mocking 후 ui만 테스트 가능.
    • ui는 ui만, 비즈니스 로직은 비즈니스 로직만 따로 분리하고자 함.
    • mocking: B에 종속적인 A를 test

• 주니어 면접 보셨음(3년차)

  • 회사의 기술적인(그린랩스 : 함수형) 부분을 잘 풀어주셔서 인상깊었다
    • 지원동기에 녹여냄
    • 유튜브 같은거 다 보고옴
    • 눈에 띔 : 우리 회사에 관심이 있구나… 장점!
  • 과제 퀄리티, 기술 면접 답변(모르는건 모른다고 해주고, 아는건 잘 설명해줬음)
  • 정말 가고싶은 회사면 회사에 관심있다고 어필해줘라!
  • 개발문화 질문
    • 현재 일하고 있던 팀의 장점을 설명해주면서 우리 팀 이만큼 좋아요~라고 설명해주신게 인상 깊었음
    • 그룹프로젝트때 같이 일했을 때 좋았던 일화~
      • 이런 부분이 팀원들이랑 잘 맞았어요~(지원자의 성향을 볼 수 있음)