이정훈

이정훈

기록을 습관화하자

1115 - 1121

1115

이전에 진행한 Shall we trip 프로젝트에서도 무한 스크롤 기능을 구현하였는데, 이번 프로젝트에서도 무한 스크롤 기능을 구현하게 되었다. 이전 프로젝트에서는 수직으로 얼마나 스크롤 됐는지를 반환하는 scrollY 프로퍼티와 뷰포트의 높이를 나타내는 innerHeight를 더한 값이 요소의 높이를 측정하는 offsetHeight를 사용해서 body 요소의 높이를 측정하고 이 값과 같은 경우 데이터를 불러오도록 구현하였다. 이 때는 스크롤 이벤트에 디바운스 처리를 해서 이벤트를 호출시켰다. 하지만 이번 프로젝트에서는 Intersection Observer API를 사용해서 이러한 기능을 구현하였다. .

Intersection Observer API

  • 타겟 요소와 상위 요소 또는 최상위 document의 viewport 사이의 intersection 내의 변화를 비동기적으로 관찰하는 방법
  • 화면에 보여지는지의 여부를 판단해서 특정 영역 내에 관찰하고자 하는 요소가 들어갔는지 나갔는지를 확인하여 교차 영역 관리를 최적화 할 수 있다.

intersection 정보가 필요한 경우

  1. 페이지가 스크롤 되는 도중 발생하는 이미지나 다른 컨텐츠의 지연 로딩
  2. 스크롤 시에, 더 많은 컨텐츠가 로드 및 렌더링되어 사용자가 페이지를 이동하지 않아도 되게 하는 infinite-scroll을 구현
  3. 광고 수익을 계산하기 위한 용도로 광고의 가시성 보고

Intersection observer의 컨셉과 사용

Intersection Observer API는 다음과 같은 상황에 호출되는 콜백을 생성하는 기능을 제공한다.

  1. target으로 칭하는 요소가 기기 뷰포트나 특정 요소와 교차함
  2. observer가 최초로 타겟을 관측하도록 요청받을 때마다

뷰포트 혹은 다른 요소를 root로 사용하건 간에, 이 API는 같은 방식으로 동작한다. 대상 요소의 가시성이 변경될 때마다 등록한 콜백 함수를 실행하며, 원하는 만큼 root 요소와 교차한다. root와 대상 요소가 교차하는 정도를 intersection ratio라고 한다. 이것은 대상 요소의 가시성 퍼센티지를 0.0 ~ 1.0의 숫자로 표현한다.

Intersection observer 장단점

IE를 지원하지 않는다는 단점이 존재하지만 감시하고자 하는 요소가 다른 요소에 들어가거나 나갈 때 실행할 콜백 함수를 등록할 수 있게 한다. 이전 프로젝트에서 사용한 방식은 디바운스 처리를 한다고 하더라도 페이지를 스크롤할 때 반복적으로 교차 탐지를 실행하게 된다. 하지만 이번 프로젝트에 적용한 방식은 사이트는 요소의 교차를 지켜보기 위해 메인 스레드를 사용할 필요가 없어지고 브라우저의 원하는 대로 교차 영역 관리를 최적할 수 있어서 유효한 방법이라고 생각한다.



1116

인성 모의 면접 피드백

인성 모의 면접 결과가 생각보다 좋았다. 좋았던 점과 좀 더 메꿔야 할 것 같다고 느낀 점을 정리해보고자 한다.

좋았던 점

  • 프론트엔드 개발자가 되게 된 계기에서는 처음에 백엔드 개발자를 희망했다가 프론트엔드 개발자를 희망하게 된 나의 경험을 토대로 전달하였는데, 이 과정에 녹아들어있는 프론트엔드 개발자에 대한 이해도나 경험을 녹여냈다는 점에서 좋은 평가를 받은 것 같다.
  • 장단점을 고민 끝에 준비하여 말했는데, 근거를 준비해서 전달하니 높은 점수를 받을 수 있었던 것 같다. 나에 대한 소개를 할 때는 항상 근거와 함께 준비하도록 하자.

부족했던 점이나 아쉬웠던 점

  • 자기 소개 때 좌우명으로 나를 소개했는데, 말이 꼬여서 어렵다는 평가를 받았다… 듣는 사람을 더 고려해서 알아듣기 쉽도록 해야겠다.
  • 이번 면접 때는 다행히 큰 지적을 받지 않았지만 내가 했던 프로젝트에 대해 더 자세하게 정리해야 할 필요성을 느꼈다.
  • 커리어 골과 협업 시 발생했던 문제점 및 트러블에 대해서는 다시 정리를 해야할 것 같다.
  • 내용은 좋았지만 좀 더 어떤 워딩을 사용하여 의견을 알아 듣기 좋게 전달할지를 고민해야겠다.

결론

전체적으로 준비한 것에 비해 좋은 평가를 받았고 나에 대해 돌아볼 수 있는 좋은 시간이었다. 어떤 부분이 부족한지를 파악했고, 어떤 점을 메꿔야 할 지에 대해 알 수 있었다.



1117

모의 코딩테스트 회고

최근에 일정이 많이 바빠지면서 계속되는 프로젝트와 면접 준비를 병행하다 보니 자연스레 코딩테스트를 준비할 시간이 적어졌다.
그리고 이번 코딩테스트에서는 예상치 못하게 다이나믹 프로그래밍 문제가 많이 나와 많은 사람들이 당황했던 것 같다.
난이도에 비해 나쁘지 않은 결과를 받았지만 DP 복습을 해야겠다는 생각이 들었다.

앞 쪽에 포진한 문제 중 비슷하지만 약간 다른 두 문제가 있었다. 동전의 개수가 무제한인 배열이 주어지고, 그 배열로 목표 금액을 구할 수 있는 경우의 수를 출력하는 문제였다. 한 문제는 경우의 수 중 순서만 다른 것은 같은 경우로, 다른 문제는 순서가 다른 것은 다른 경우로 경우의 수를 출력해야 했다.

두 문제 해결하지 못해서 다시 한 번 풀어보았다.

순서가 다른 것은 같은 경우

const solution = (nums, m) => {
  const dy = Array(m + 1).fill(0);
  dy[0] = 1;

  for (let i = 0; i < nums.length; i++) {
    for (let j = m; j >= 1; j--) {
      let k = 1;
      while (j - nums[i] * k >= 0) {
        dy[j] += dy[j - nums[i] * k];
        k++;
      }
    }
  }

  return dy[m];
};
  • 실제 모의 코딩테스트 중에는 DFS로 모든 경우를 구하고 순서만 비교하여 정확도라도 맞히려했는데, 정확도에서마저도 시간 에러가 발생했다.
  • 두 문제 모두 dy[i]는 i원 까지의 경우의 수이다.
  • 이전에 풀었던 동전 바꿔주기 문제와 상당히 유사한대, 그 때는 동전의 개수가 정해져 있었다면 이 문제에서는 동전 개수를 무제한으로 사용할 수 있다는 차이점이 있었다.
  • 그렇기에 2중 포문까지의 로직은 같지만, 가장 내부 로직에서는 그저 목표로 하는 돈에서 동전 단위 x 개수가 0보다 크거나 같을 때까지 모두 더해서 목표 돈까지의 경우의 수를 구해줬다.
  • 이 로직을 동작하도록 하기 위해 dy[0]은 1로 초기화해줬다.

순서가 다른 것은 다른 경우

const solution = (nums, m) => {
  const dy = Array(m + 1).fill(0);

  nums.forEach((num) => {
    dy[num] = 1;
  });

  for (let i = 1; i <= m; i++) {
    let sum = 0;
    for (let j = 0; j < nums.length; j++) {
      if (i - nums[j] < 0) continue;
      sum += dy[i - nums[j]];
    }

    dy[i] += sum;
  }

  return dy[m];
};
  • 위의 문제와는 다르게 순서가 다른 경우는 각각 다른 경우로 계산하여 경우의 수를 반환해줘야 했다.
  • 그렇기에 돌다리 건너기 문제와 유사한 방식으로 해결했다.
  • 우선 동전 배열에 있는 인덱스에 값을 1로 초기화해줬다.
  • 그리고 dy를 순회하며 해당 인덱스에서 동전 배열에 있는 값만큼 뺀 곳에 위치한 경우의 수를 모두 더해 해당 인덱스에 더해줬다.



1118

기술 모의 면접 피드백

컨디션이 너무 좋지 않아서 엄청 못봤다고 생각했는데, 생각보다 좋은 결과가 나와서 놀랐다. 다시 한 번 회고를 진행하며 부족했던 점들을 채우고자 한다.

좋았던 점

  • 모의 면접을 진행할 때 자기소개나 프론트엔드 직무 파악에 대해 좋은 평가를 받는 것 같다. 이 틀을 유지하되 조금 더 메꿔서 말할 수 있도록 해야겠다.
  • SPA의 장점에 대해 원하던 답을 제공한 것 같다. 이 부분은 매력 포인트로 작용할 수 있다고 하니 조금 더 학습하여 온전히 내 것으로 만들어야겠다.

부족했던 점이나 아쉬웠던 점

  • 프론트엔드 직무에 대해 필요한 능력으로 협업능력과 사용자 관점으로 설명했는데, 기술적인 부분으로 성능을 향상시키는 데에 어필하는 연습도 해야될 것 같다.
  • 모든 프로젝트에서 가장 어려웠던 점이 무엇이었는데, 어떻게 해결했는지를 정리해야 할 필요성을 느꼈다. 그리고 이를 설명할 때 말을 실수해서 다른 의도로 전달되도록 한 것 같은데 가장 좋은 개발은 공식 문서에 나와있는 best practice 대로 하는 것이라고 한다. 공식 문서를 처음부터 끝까지 정독해서 가장 간단한 구조로 구현한 후에 기능을 덧붙여 갔다고 해결방법을 언급해주면 더 좋은 인상을 줄 수 있을 것이라고 한다.
  • 식별자에 대해 질문했을 때에 그에 대해 정확한 답변을 주지 못했다. cs적으로 어떠한 의미인지 용어에 대해 한 번 더 정리해야 할 필요성을 느꼈다.
  • 프로미스에 관련된 질문을 받았는데, 프로미스를 반환하는 함수를 호출한다는 것이 머릿속에서 바로 그려지지 않아 당황한 기억이 있다. 이에 대해 다시 한 번 정리해야 할 필요성을 느꼈다.

결론

기본적인 용어 정리를 다시 한 번 하자.
자바스크립트 책을 빠르게 한 번 복습하자.
프로젝트에 대한 정리를 꼭 하자. 가장 중요한 점은 가장 어려웠던 점을 말하고, 이를 어떻게 해결했는지 과정과 어떤 결과를 냈는지 정리하는 것이다.

식별자

  • 변수 이름을 식별자라고도 한다. 식별자는 어떤 값을 구별해서 식별할 수 있는 고유한 이름을 말한다.
  • 식별자는 메모리 공간에 저장되어 있는 값을 구별해서 식별해낼 수 있어야 하므로, 어떤 값이 저장되어 있는 메모리 주소를 기억해야 한다.
  • 변수, 함수, 클래스 등 메모리 상에 존재하는 어떤 값을 식별할 수 있는 이름은 모두 식별자라고 부른다.
  • 식별자는 네이밍 규칙을 준수해야 하며, 선언에 의해 JS 엔진에 식별자의 존재를 알린다.

태그:

카테고리:

업데이트:

참고