3주차 멘토링

질문과 답변

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

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

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

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

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

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

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

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

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

• React.Memo : 컴포넌트의 props가 변경되지 않는 이상, 재렌더링되지 않는다

  • React.Memo 를 사용한다면 재랜더링을 막을 수 있으므로 useCallback을 쓸 필요가 없어진다
  • 컴포넌트가 자주 렌더링되어야 할 때 (초당 10번 이상) => useCallback의 유무에 대한 차이가 커진다
  • 허나 이런 케이스는 흔치 않다
  • handleClickEditButton을 하위 컴포넌트에 props로 내려주면서 이를 useEffect 등으로 종속성을 걸 경우, 하위 컴포넌트에 side-effect가 발생할 수 있다
  • 태그 안에 중괄호를 열고 prop으로 화살표 함수를 선언하는 방식도 이렇게 선언하는 것과 다를 바가 X

• [].map((v) => {<button onClick={() => handleClickEditButton(v)}>}

  • 이런 경우 useMemo로 메모이제이션 (배열이 바뀌지 않는 이상 렌더링을 다시 하지 않는 방식)
  • 리스트에 내용이 너무 많거나, 많은 내용을 렌더링해야 할 때 useMemo를 사용하면 좋다
  • 페이지는 자주 변경되지만 리스트 내용물이 거의 바뀌지 않는다면 useMemo를 사용하면 좋고, 자주 바뀌면 useMemo가 의미 없다

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 백엔드: 부하 테스트?

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

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

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

• 프론트엔드도 테스트를 하고 시간이 남으면 새로운 Feature에 도전해 보세요

  • 실무에서는 보통 테스팅이 서비스 개발에 밀리는 경우가 많아, 이러한 경험이 있으면 매우 좋음

• 로그인 / 비로그인 테스트 등, 케이스를 모두 나눠서 테스팅해야 한다

• 성능 테스트는 사람이 직접 손을 대서 테스팅하는 경우가 많다

  • 초당 접속자 수를 사람이 직접 조정하고, 올리다 보면 성능이 떨어지는 순간이 온다
  • 그 그래프를 보고, 하나의 컴퓨터에서 몇 명의 요청을 처리할 수 있는지 판단할 수 있다
  • 이를 이용하여 몇 대의 컴퓨터가 필요할지 파악할 수 있다

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

• 말하는 것은 좋아보이지만, 딥하게 들어갈 필요는 없을 것 같다 (금방 넘어갈 만한 내용일 듯)

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

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

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

• 현재 특정 페이지에 공통으로 적용되는 레이아웃을 중첩 라우팅으로 구현하였고, 로그인 체크 기능을 중첩 라우팅으로 구현했다가 '라우팅 (경로 선택)' 과 크게 관련이 없다고 생각되어 상위 컴포넌트로 분리하였습니다

• 중첩 라우팅을 이용하여 구현하는 케이스와 상위 컴포넌트로 배치하는 케이스로는 어떤 것이 있을까요? 명확하게 분류할 만한 기준이 있을까요?

• 리액트 라우터를 사용하지 않는 이유

  • 데이터를 Fetch하지 않은 상태의 컴포넌트를 렌더링함
  • SSR에서 요구하는 것: Document를 브라우저에서 받자마자 모든 데이터들이 들어있는 상황을 원함
  • 단 리액트 라우터를 사용하면 빈 레이아웃을 먼저 렌더링한 뒤 데이터를 불러오므로, SSR에는 부적합하다
  • Universal Router => 올드한 라이브러리이지만, 이런 부분에서 SSR에서 이점을 갖는다

• 사실 SSR은 Next 를 사용하면 알아서 다 해준다

• 로직만 수행하는 경우 (props를 내려주지 않는 경우) 그냥 커스텀 훅으로 분리하는 것을 추천

앞으로 하고자 하는 도전

• 프론트엔드

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

• 백엔드

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