깊고 넓은 삽질

프론트엔드 테스트 코드 작성에서 사용되는 보편적인 라이브러리가 RTL(React-Testing-Library)라고 한다. 해당 라이브러리를 사용하려고 보니 CRA로 만든 프로젝트에서는 기본적으로 환경설정이 되어 있지만 vite는 따로 설치하고 설정해줘야할게 많았다. React 테스트 환경 구축하기 create react app으로 react 애플리케이션을 생성하면 이런 문제에 관해 크게 고민할 일이 없으나, 전 cra에서 snowpack을 거쳐 요즘은 vite를 쓰고 있기에, 테스트 환경을 알아서 구축해줘야 합니다. 참고 marshallku.com 과정이 무척 복잡하기도 하고 각 설정이 뭘 의미하는지 찾아보다가 vitest라는 것을 발견했다. vite가 친절하게 why vite를 설명해준것처럼 vites..

웹 서비스를 기획부터 배포, 운영까지 할 기회가 생겨 그 과정을 기록하고자 한다. 좋은 기회를 준 친구에게 감사의 마음을 전한다. 1. 기획 | 짝선배 짝후배 문화 이어가기 친구의 대학교에는 짝선배 짝후배 문화가 있다. 신입생의 학교 적응을 위해 선배와 짝을 지어주는 문화라고 한다. 학생회에서 주최하는 프로그램이었는데 문제는 학생회가 사라지면서 이 문화도 흐지부지 사라질 위기에 처했다. 좋은 문화의 명맥을 이어가기 위해 나와 내 친구 둘이서 웹사이트를 운영해보기로 했다. 웹사이트의 기능은 간단하다. 사용자가 본인의 정보와 원하는 탐색 범위를 제출하면 해당 범위에 적합한 상대를 이어주는 것이다. 개발 일정은 2월 초에 시작해 3월 개학 이전까지 배포를 목표로 잡았다. 원하는 탐색 범위 받기 사용자가 원하는..

장바구니 구현 시 고려할 점 | 수량 변경과 선택 이커머스 사이트에서 중 장바구니 페이지를 구현하고 있다. 장바구니 페이지는 결제 페이지 바로 이전 페이지로, 장바구니에 담긴 물품들 중 체크된 품목만을 결제 페이지로 넘겨준다. 체크나 품목 수량 변경을 할 때 각각의 물품 id와 수량을 알 수 있기 때문에 해당 id로 PATCH api를 보내면 간단하게 구현할 수 있을 거라 생각했지만, 전체 선택을 할 때 어떻게 구현할 지 고민이었다. 각 아이템들의 체크 여부를 확인해 각각의 아이템 id로 아이템 수만큼의 PATCH api를 날려야 하나? 어떤게 효과적일지 프론트엔드 엔지니어의 작은 두뇌로 고민해봤다. api에 대한 best practice는 github를 많이 참고하고 있다. 하지만 github에서는 적..

면접회고 | 멀티스레드, 멀티프로세스, SPA 운 좋게 면접을 볼 기회가 있었다. 기술면접을 보고 바로 인성면접을 봤다. 4시에 면접이 시작됐는데 체감상 각각 15분씩 30분정도 걸린 것 같았다. 끝나고 나와서 시계를 보니 6시였다. 멀티 스레드와 멀티 프로세스 질문이 가물가물한데 맥락은 이러했다. 자바스크립트로 개발 시 멀티 스레드와 멀티 프로세스를 이용한 구현의 비교를 물어보셨다. 내가 알고있는 건 프로세스는 실행되고있는 프로그램이고, 스레드는 프로세스 안에서 실행되는 것 정도였다. 프론트엔드 분야에서 내가 알고있는 프로세스와 스레드는 "자바스크립트는 싱글 스레드 언어,, "로 시작되는 이벤트루프, 테스크큐, 콜스텍과 실행컨텍스트에 대한 설명 뿐이었다. 자바스크립트 멀티스레드, 멀티프로세스라는 키워드..

리팩터링의 전제 조건은 리팩터링 후에 정상 동작하는 것이다. 리팩터링 후 정상적으로 동작하는지 확인하기 위해서는 테스트가 필요한데, 테스트 자동화가 되어있지 않아 많이 불안한 상태였다. 자동화가 되어있지 않으면 사람의 눈으로 확인하기 때문에 정확하지 않을 수 있고 확인하는 데에 시간이 많이든다. 만약 여러 코드가 의존하고 있는 부분을 리팩터링 한다면 그 부분을 의존하고 있는 코드들을 모두 테스트해봐야 정확한 테스트가 가능한데, 이는 사람이 하기엔 너무 많은 일이다. 하여, 늦었지만 지금부터라도 테스트 자동화를 위해 테스트 코드를 짜 보고자 한다. 테스트 자동화 환경 설정 (jest) ⬇ 더보기 yarn add --dev jest jest-environment-jsdom @testing-library/re..

밀린 리팩터링 조지기 5월쯤 부터 시작한 티 플랫폼 사이트 개설 프로젝트 teave가 어느덧 5개월이 지나고 있다. 그간 나름의 리팩터링을 해왔었지만 최근 한 달동안은 기능 구현에만 초점을 맞췄던 것 같다. 이제 곧 teave 팀에서 나가야 하는데 후임 프론트 엔지니어에게 이 상태로 넘겨 줄수는 없다. 현재 teave의 프론트엔드 코드는 구조가 뒤죽박죽 되어있다. 처음부터 끝까지 나 혼자 짠 코드들이지만 중간중간에 새로운 패턴을 학습해 적용해 여러 패턴이 섞여있다. 이를 하나의 직관적인 패턴으로 통일하는 것이 1차적인 목표다. 2차 목표는 컴포넌트 분리다. 플랫폼 사이트 특성상 비슷한 컴포넌트들이 많다. 그런데 각자 역할과 기능이 조금씩 달라서 새로 만들다 보니 현재 여러 컴포넌트들에서 중복되는 부분이 ..