Programming Is Hard

이번 주차 목표 (프런트엔드 테스트 코드)(1) 테스트의 필요성을 이해한다.(2) 기본적인 테스트를 작성할 수 있다. 1. 고민했던 문제- 통합 테스트를 진행하면서 mock 데이터를 생성하고 리스트에 반영하는 흐름이 자연스럽게 연결되었는지 판단하기 어려웠고, 실제로 테스트가 여러 번 실패하면서 디버깅에 시간을 많이 썼다.하지만 그 과정에서 비동기 렌더링 타이밍, 상태 반영 시점 등을 파악하게 되면서 테스트에 대한 이해도가 확실히 높아졌다. 2. 시도 및 해결- 이전에는 렌더링 안정화를 위해 waitFor를 사용했지만, 비동기 로직이 없는 경우에는 await act(() => null)처럼 최소한의 act 호출만으로도 충분하다는 점을 멘토링을 통해 알게 되었고, 이를 코드에 반영해 개선했다.// 개선..

이번 주차 목표 (관심사 분리와 폴더구조)(1) 단일책임원칙이 적용된 좋은 폴더 구조를 안다. 1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)- Jotai와 Tanstack query를 함께 사용할 때의 일관성TanStack Query가 “요청 → 캐싱 → 로딩/에러 관리”의 역할을 해준다는 점은 이해했지만, 기존 상태 관리의 actions 역할을 어디까지 위임할 수 있는지가 애매하게 느껴졌다.예를 들어 기존에는 addComment, updatePost 등의 상태 변경 로직을 Jotai 기반으로 직접 관리했는데, 이런 동작들을 이제는 mutation으로 옮겨야 하나? 아니면 여전히 Jotai로 관리해야 하나?로컬 상태와 서버 상태의 책임 분리가 뚜렷하지 않아서 혼란스러웠다. 2. 시..

이번 주차 목표 (디자인 패턴과 함수형 프로그래밍)(1) 값 함수 액션을 구분할 수 있다. 1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)- ProductManager 추상화현재 새 상품 추가는 ProductForm 컴포넌트로 분리했지만, 기존 상품 수정 영역은 핸들러 함수가 많아져 UI와 로직을 분리하지 못했다.특히 setEditingProduct를 직접 다루는 handleProductNameUpdate, handlePriceUpdate, handleStockUpdate처럼 필드별로 상태를 갱신하는 로직이 반복되면서 코드가 점점 길어지고 중복되는 느낌이 들었다. - 액션과 순수함수 분리에 대한 고민로직을 어디까지 hook 안에 두고, 어떤 계산을 utils 또는 models로 분리해..

이번 주차 목표 (클린코드와 리팩토링)(1) 내가 작성한 코드가 클린코드임을 설명할 수 있다.(2) 클린하지않은 코드를 클린하게 만들 수 있다. 1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)- 화요일에 대한 테스트코드 실패할인과 포인트 계산에 대한 테스트 코드가 계속 실패해서 calcCart 함수의 로직을 여러 번 수정했다. 알고 보니 로직이 틀린 게 아니라, 테스트 시점의 날짜가 실제로 화요일이라 할인 로직이 정상 작동한 것이 원인이었다. 테스트에 실패하자 일부러 수요일로 바꾸고 흐린눈으로 넘겼던 기억도 있다... 😭 - React 마이그레이션 시 코드 작성과 구조 분리의 어려움Basic 코드에서 사용하던 로직을 그대로 React로 옮긴 뒤 개선을 시도했지만, "React에서는 ..

🙋‍♀️ 간단한 자기소개 저는 AI-OCR 문서 자동화 시스템을 개발하고 있는 4년 차 프론트엔드 개발자 김유빈입니다. Vue와 Typescript를 주로 사용해왔고, 최근에는 Javascript 딥다이브와 React 생태계를 공부하고 있습니다.벌써 항해를 시작한지 3주가 지났네요. 1챕터는 JS & React 딥다이브였는데요! 그동안의 경험을 돌아보며 회고해봅니다. 🎯 이번 챕터를 시작하며 꼭 해내고 싶었던 목표 여러 목표가 있었지만, 가장 중요하게 생각한 건 공부하는 습관을 들이는 것이였습니다. 퇴근하고 앉아서 공부하는 거 힘들잖아요?기술적인 목표로는 두 가지를 세웠습니다.Vanilla JavaScript 코드에 대한 두려움 없애기React의 동작 원리를 이해하고 사용하는 개발자 되기  🏆 이번..

이번 주차 목표 (프레임워크 없이 SPA 만들기)(1) 가상 DOM을 정의하고 사용할 수 있다.(2) 가상 DOM을 이용하여 이벤트 관리를 최적화할 수 있다.(3) diff 알고리즘을 이용하여 불필요한 렌더링을 최소화할 수 있다.  1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)- 전체적인 가상 DOM 구현가상돔 개념은 Vue와 React가 이를 기반으로 만들어진 프레임워크라서 익숙했다. 아무래도 기술면접에서도 자주 나오는 질문 사항이니깐.직접적으로 구현하는 건 처음이었는데, 개념적으로 이해하는 것과 실제로 구현하는 것의 차이를 실감했다... 진짜 어려웠다. - 이벤트 핸들러 구현createElement와 updateElement 내부에서 이벤트 핸들러를 다루는 부분이 까다로웠다. 가능..

1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)대표적으로 3가지로 분리할 수 있을 거 같다. - 라우터 + 렌더 구현직접 라우터를 구현하는 것이 예상보다 훨씬 어려웠다. 평소 프레임워크가 알아서 처리해주는 부분에 대해 새삼 감사함을 느꼈다...(따봉 Vue야 고마워!) 단순히 history.pushState()만 사용하면 될 줄 알았으나, 실제로는 화면 전환 로직을 따로 조정해야 했고... 렌더링 시점을 원하는 대로 컨트롤하기 어려웠고, 이 부분에서 큰 어려움을 겪었다.- 배포GitHub Pages는 프론트엔드 개발자가 쉽게 접할 수 있는 배포 서비스이자, 웹사이트를 무료로 호스팅하기도 쉬운 편이라 가볍게 생각했는데, 라우팅이 제대로 되지 않아 404 페이지에 막혀 고생길을 건넜다.- ..

1. 지금까지의 회고Django + Vue.js를 사용하는 풀스택 웹 개발자로 시작해 온전히 Vue.js만을 사용하는 프론트엔드 개발자로 성장해왔다. Vue.js에서의 전문성을 쌓는 것도 즐겁고 재밌었지만... 사회에 나가야겠다 마음 먹고 이직을 고려하며 시장을 둘러보니, 대부분의 회사는 React를 대부분 사용하는 것을 알게 되었다.Vue.js만을 사용할 줄 아는 나에게 바깥 세상은 너무 낯설고 외로웠고... React를 필수적으로 배워 실무에 사용해야겠다! 라는 마음가짐을 갖게 되었다. 사실 프론트엔드 개발자로 쭉 살아갈 거면 더 열심히 개발 공부를 했어야 했는데... 퇴근 후 책상 앞에 앉아 공부하는 것은 결코 쉬운 일이 아니었다.2. 항해 플러스 참여 계기요즘 JD를 확인해보면 'React 실무 ..