문제 설명첫 접근 방향네 개의 주사위에서 나온 숫자의 중복 형태에 따라서 점수를 계산하는 문제였기 때문에, 일단은 가장 쉬운 방식으로 접근해보기로 했다.a, b, c, d 모든 숫자에 대해서 각각의 조건을 만족하는 조건문을 작성해보려고 생각을 했는데, 네 개의 조건 비교만으로도 너무 많은 노다가를 필요로 했다.if (a === b && b === c && c === d) { // 모두 같은 경우 }위와 같이 작성을 해보려다가 바로 잘못된 접근 방식인 것을 확인하고 다른 방향으로 접근해야겠다고 생각했다.숫자를 직접 비교하는 대신 각 숫자가 몇번 등장했는지 세자.각 숫자의 등장 횟수를 세기 위해서는 Map을 사용하는 것이 가장 효율적이라고 판단했고 다음과 같이 코드를 작성했다.const dice = [a, ..
최근 회사에서 기존 프로젝트 마이그레이션을 진행중이다. 자사 앱을 사용해서 의료 데이터를 쌓아온 유저에게 통합 데이터를 제공하는 서비스인데,다루는 데이터가 사용자의 민감한 의료 데이터다 보니 기존 레거시보다 보안과 데이터 제어에 신경을 써야했다. (도입계기에 대해서는 추후 별도의 블로그 포스팅으로 더 자세하게 풀어보겠다.) 아무튼 Remix를 통해 SSR 프로젝트로의 마이그레이션을 진행하던 도중 문득문득 개발하면서 이전에 올렸던 블로그 포스팅이 떠올랐다. 당시에는 이론적으로 '정의'에 대해서 좀 집중했다면, 실제 프로덕션 레벨에서 SSR을 마주하다보니 좀 더 체감이 컸다. 개발하면서 이전 블로그 포스팅에서 떠올랐던, 그리고 강조했던 핵심 부분은 다음과 같다."MPA와 SSR, SPA와 CSR를 동일하다고..
들어가며졸업, 취준 이후에 프론트엔드 개발자로서의 1년이 지나갔다. 조금 늦은 회고록이지만, 아직도 가끔은 스스로에게 물을때가 있다. "과연 나는 1년차 개발자 답게 살고 있을까?" 취준생일 때 상상했던 1년차 개발자는 혼자서 어느정도의 문제는 술술 해결할 줄 아는 개발자였지만, 실제로 경험한 1년차는 여전히 주니어였고, 술술 해결하기보다는 조금 덜 헤매고, 조금 더 익숙해진 정도였다. 신입이었던 나의 1년전 모습과 지금 모습의 차이를 꼽자면, 이제는 회사의 비즈니스 도메인과 워크플로우가 몸에 익어 문서를 들락날락하지 않아도 자연스럽게 일을 할 수 있다는 것 정도라고 생각한다. 돌아보면, 1년동안 가장 많이 성장하고 배웠다고 생각한 순간들은 실제 프로젝트에 참여해서 부딪힌 경험에서 나왔다.이전에 현업에 ..
덕풀 프로젝트가 성공적으로 끝나면서 리팩토링 해야 할 부분을 지속적으로 찾기 시작했다. 확실히 프로젝트를 실제로 사용하면서 이미지의 레이아웃 시프트, 이미지 리소스 용량 비대와 같은 문제점을 발견했고, 해당 부분을 좀 더 개선시켜야겠다고 생각했다. 홈 페이지를 기준으로 덕질자랑과 덕질토크의 최근 10개 게시물을 불러오도록 하고, 실제 유저에게는 swiper를 사용하여 덕질자랑과 덕질토크 게시물 각각 데스크탑 기준 5개, 4개 모바일 기준 3개, 2개의 이미지만 보여지게된다. 이 때 총 20개의 이미지 리소스를 모두 다운로드 받게되면 페이지 로딩 시간이 길어지는 문제가 발생했다. 이 부분을 Lazy Loading을 통해 성능적으로 많은 개선을 이루어서 해당 포스팅을 통해 소개해보고자 한다. 가장 먼저 이미..
서비스를 구현함에 있어서 에러처리는 굉장히 중요한 부분이다. 실제로 유저들이 서비스를 사용하면서 에러가 발생했을 때 그에 따른 처리를 구현해놓지 않는다면 사용자는 에러로 인한 터진 애플리케이션을 보게되고, 현재 서비스에 어떤 문제가 있는것인지 유저들은 확인할 수 있는 방법이 없다. 따라서 고스란히 서비스에 대한 신뢰성 하락과 유저 이탈로 이어질 수 있다. 여러 프로젝트를 진행하면서 에러처리에 신경을 썼다고 생각했지만, 에러가 발생할 만한 컴포넌트 내에서 에러 처리를 해준다거나 try catch를 남발하는 등,, 지금 돌이켜보면 효과적으로 에러처리를 진행하지는 못한 것 같다. 따라서 덕풀 서비스를 구현하면서 에러처리 중앙화에 대해서 고민했던 상황들을 소개해보고자 한다. 발생 가능한 에러 상황 나는 덕풀 프..
이번 포스팅은 "덕풀" 프로젝트를 진행하면서 애플리케이션 유저 상태와 인증 로직을 관리한 방법에 대해 이야기 해보고자 한다. 모달 전역 관리에 대해서 소개했던 지난 포스팅에서는 뷰와 더 밀접하고, 애플리케이션 전체 뷰 뿐만 아니라 서브 뷰에서도 사용이 용이하기 때문에 Context API를 사용했다고 소개했지만, 유저 상태 및 인증 로직은 애플리케이션 전체에서 단 하나만 존재해야하는 앱 상태 그 자체이고, View의 라이프 사이클과 무관하게 애플리케이션 자체의 라이프 사이클을 따라가는 영속적인 상태이기 때문에 전역관리 라이브러리인 Jotai를 사용하여 구현했다. 일단 위에서 언급했듯이 전역 상태 라이브러리를 통해서 유저 상태와 인증 로직을 관리한 이유에 대해 설명했으니, 들어가기에 앞서 전역 상태 라이브..
오랜만의 포스팅이다! 3달 동안 프로젝트를 진행하느라 포스팅을 미루고 미루다가, 드디어 배포를 끝내고 아껴놨던 포스팅거리들을 풀 시간이 된 것 같다. 이번에는 "덕풀"이라는 덕질 공유 플랫폼 프로젝트를 개발했는데, 혼자서 개발 환경 세팅, 기능 개발, 배포까지 A to Z를 해야하다보니 중간중간 지칠때도 많았던 것 같다. 역시 개발은 여러명이서 함께해야 즐거워,,, 이번에 작성할 블로그 주제는 프로미스를 사용한 전역 모달 관리다. 이전의 프로젝트를 진행하면서도 전역 모달 관리를 사용했고, 관련해서 블로그 포스팅도 썼는데도 불구하고 다시 한 번 같은 주제를 들고왔다. 이전의 전역 모달 관리 방법을 "덕풀" 프로젝트에서도 사용하려고 보니 생각보다 효율적이지 않은 부분이 많다는 것을 알게되었고, 해당 문제점들..
다들 React를 처음 공부할 때 여러가지 훅의 쓰임새와 활용방법등을 공부하면서 useMemo와 useCallback이라는 훅을 접해봤을 것이다. 처음 내가 useMemo와 useCallback을 공부했을 때 사용이유는 다음과 같았다. - useMemo는 계산 비용이 높은 연산의 결과를 기억하고, 의존성 배열에 넣어준 deps가 변경되지 않으면 계산한 값을 재사용한다. - useCallback은 함수를 메모이제이션하고, 의존성 배열에 넣어준 deps가 변경되지 않으면 이전에 생성한 함수를 재사용한다. 두 훅 모두 React를 사용하면서 렌더링 성능 최적화를 위해 사용하는 훅인데, 사실 사용하지 않아도 개발자 경험에는 큰 영향을 주지않는다. 사실 큰 영향을 주지않는다기보다 개인적으로 아직 내 실력과 경험이..
