3주차 멘토링

질문과 답변

1. 컴포넌트 내에서 함수를 활용하는 방법

1. useCallback
2. 별도 파일에 명시해놓고 import 해오기
3. 컴포넌트 내에서 useCallback 없이 함수 사용

• useCallback도 메모리 비용이 든다, 딱 정해져 있는 건 아니라서 개발자 각각의 선택으로 구현하게 됨

• useCallback을 지양하는 경우가 더 많다

  • 메모이제이션으로 얻는 이득보다 손해가 더 많다
  • Dependencies 를 일일이 지정해주어야 하기도 함

• useCallback을 언제 쓰거나 언제 안 쓸까?

  • 하위 컴포넌트에 함수를 전달해야할 때 보통 useCallback을 많이 사용함
  • Dependencies가 너무 많을 경우 useCallback 지양
  • 엄청나게 많은 로직이 함수에 포함될 때만 useCallback을 자주 사용하고, 아니면 지양하는 편

• 함수를 다른 파일에 빼서 import하는 것은 어떨까?

  • 비즈니스 로직을 담고 있는지? 아니면 컴포넌트 안에서만 사용하는 코드인지? 에 따라 컴포넌트에 둘지, 다른 폴더에 분리할지 결정
  • 컴포넌트에 있는 로직은 테스트하기 위해 UI 테스트를 수행해야 하지만, 비즈니스 로직은 별도 파일에 분리하는 것이 테스트를 고려했을 때 훨씬 좋다
  • 컴포넌트 테스트는 매우 번거롭다~~ (테스트코드 짜는 비용이 크고, 배보다 배꼽이 커진다)

• 별도 파일에 함수를 분리했을 때와, useCallback을 이용할 경우 렌더링 시에 차이가 없을까?

  • useCallback은

2. 기능적 다양성보다 기능의 완성도, 안전성을 높이는 데 힘을 쏟고자 하는데, 이런 방향성이 멘토님이 보시기에도 매력있게 느껴지시는지(만약 면접자의 입장이시라면)

현재 기존에 계획했던 기능은 다음 주 이내로 끝낼 수 있을 것으로 예상된다.

나중에 면접에서 해당 프로젝트를 진행하면서 극복했던 기술적 어려움이나, 우리의 도전을 보여줘야할 것 같은데

남아있는 애매한 기간 동안 기술적 도전(ex. 채팅)이나 기획적인 무언가를 하기에는 완성도가 떨어질 것 같다는 생각을 했다.

고민하던 차에, 기본 계획을 끝내고 나서는 테스트에 집중해보려한다.

기존 프로젝트 완성도도 높이고 테스트는 처음 해보는 거라서 여러가지 테스트 툴이나 방법을 사용해보면서 새로운 도전을 보여주고자 한다.

이러한 우리의 방향성이 멘토님 입장에서 보시기엔 어떠신지 의견을 여쭙고 싶다.

• 테스트코드도 금방 할 수 있을 듯 하다 (솔직히 그렇게 어렵진 않다, 공부 시작하면 하루에 8시간씩 3~4일 정도?)

• E2E, Jest 등 예제를 보다 보면 다 비슷비슷하기 때문

• 백엔드는 Postman으로 테스트케이스를 전부 짜낼 수 있다

  • 코드로 테스트케이스를 만드는 것도 방법이고, Postman으로 테스트케이스를 만들어서 전체 테스트 기능을 사용할 수도 있다
  • 조금 더 쉬운 방향으로 가 본다면 금방 끝낼 수 있을 것이다

• Test Coverage Report setup을 해보는 것을 추천

  • 테스트코드가 얼만큼의 코드를 커버하는지? 어떤 코드가 제대로 동작하지 않았는지?
  • 커버리지를 최대한 올리는 방향으로 작업해 보자

• UI 개선은 별로 의미가 없다

  • 보기에는 좋겠지만 질문거리나 기술적인 문제는 거의 없다

• 백엔드: 부하 테스트?

  • Access Log 로깅하기
  • 사용자 유입 파악, 대놓고 해킹 시도하는 사람 (자동화된 공격 코드 등) 확인 / 그에 대해 어떠한 응답을 했는지 여부 확인 가능

• Github Action으로 배포 성능을 올리는 것은 유의미하지 않다

  • Github Action은 일반적이진 않다
  • 대부분 쿠버네티스를 사용함 (배포 이미지 빌드 => 이미지를 저장소에 올려둔 뒤 쿠버네티스를 통해 배포)
    • 쿠버네티스는 속도가 엄청나게 빠름
    • nCloud와 같은 한정적인 환경에서 배포 속도를 올리는 건 유의미하진 않을 듯 (해보면 좋긴 함)
    • CI 성능을 올리기 위해서 주로 좋은 컴퓨터를 사용
  • 성능상 발전이 없다면 하나의 빌드를 쪼갤 수 있는 방법을 찾아봄
    • 유틸 코드 분량이 너무 커질 경우, 변경이 거의 일어나지 않는 코드를 별개의 프로젝트로 분리한 뒤 빌드해서 가져다 쓰기만 함
    • 그 코드는 바뀌지 않는 이상 빌드할 필요가 없으므로
  • 다른 Feature를 하는 것이 좋을 것 같아요

3. 면접을 진행할 때, 기술적으로 겪은 어려움을 해결한 내용말고 기획에서 경험한 어려움을 해결한 과정 등도 이야기 할 수 있는지?

4. 단위 테스트 어느정도까지 해야할까요?

• 좋아요 기능을 담당하는 controller, service, repository 가 있을 때, service 에 만들어놓은 모든 함수를 하나씩 테스트하면 되는 걸까요??
• 단위 테스트가 불가능한 경우는 어떤 게 있나요?

5. 중첩 라우팅의 적절한 사용례

• 현재 특정 페이지에 공통으로 적용되는 레이아웃을 중첩 라우팅으로 구현하였고, 로그인 체크 기능을 중첩 라우팅으로 구현했다가 '라우팅 (경로 선택)' 과 크게 관련이 없다고 생각되어 상위 컴포넌트로 분리하였습니다
• 중첩 라우팅을 이용하여 구현하는 케이스와 상위 컴포넌트로 배치하는 케이스로는 어떤 것이 있을까요? 명확하게 분류할 만한 기준이 있을까요?

앞으로 하고자 하는 도전

• 프론트엔드

  • useMemo, useCallback 등을 사용하여 최적화 시킬 때, 실제 성능에 어떤 차이가 있는지 연구하고, 성능을 높이기 위해 어떻게 하면 좋을지 학습하기
  • react testing library 를 사용하여 React 컴포넌트 자체를 테스트
  • Jest 를 이용한 내부 로직 테스트

• 백엔드

  • 만든 API 의 테스트 코드를 짜기, 테스트 프로그램(?)을 이용해서 요청 수에 비례한 성능을 확인하고, 성능을 높이기 위해 어떻게 하면 좋을지 학습하기
  • Github Actions 를 이용하여 배포(CD)할 때, 배포 성능(= 배포 속도)을 높이기 위한 방법 찾기