Sally의 React/TypeScript 여정
-
초기 감정과 적응: Rails 백엔드와 React/TypeScript 프론트엔드 프로젝트를 진행하며 초기에는 불만을 가졌으나, 점차 적응하며 긍정적인 면도 발견했습니다.
-
테스트 작성의 어려움: 가장 큰 어려움은 JavaScript/React 컴포넌트 테스트 작성으로, Mocking의 필요성과 통합 테스트의 어려움, 그리고 CI 커버리지 측정 방식에 대한 불만을 표했습니다. Rails 개발 시에는 익숙했던 테스트 전략 수립 능력이 React에서는 부족하여, 컴포넌트 로직 추출 및 파일 크기 관리 등에 어려움을 겪었습니다.
-
React Hook Form의 유용성: 긍정적인 부분으로는 React Hook Form의 사용이 예상보다 쉽고 효율적이었다고 언급하며, 폼 상태 관리 및 상호작용에 있어 ‘마법 같은’ 경험을 제공했다고 평가했습니다.
-
지속적인 과제: 하지만 여전히 React의 잦은 리렌더링과 불필요한 네트워크 호출 등은 Rails 개발자로서 불안감을 유발하는 요소로 지적하며, React 생명주기와 렌더링 성능 이해가 다음 학습 단계임을 언급했습니다.
Joel의 타입 시스템 가치 탐구
-
타입의 가치 재정의: TypeScript 프로젝트를 진행하며 타입 시스템이 버그 방지에 기여하는 가치에 대해 심도 깊게 탐구했습니다. 일반적인 인식(툴링 지원)과 달리, 타입이 버그를 효과적으로 방지할 수 있다고 주장하며, 타입 시스템을 ‘일관성 검사 시스템’으로 정의했습니다.
-
타입 시스템 이해도 여정: 개발자의 타입 시스템 이해도 여정에 따라 그 가치가 달라진다고 설명하며, 초기에는 타입 검사기를 ‘달래야 할 대상’으로 인식하지만, 궁극적으로는 ‘짝 프로그래머’로서 설계 및 구현을 돕는 대화의 도구가 된다고 강조했습니다.
-
버그 방지 메커니즘: 특히, Ruby의
NoMethodError와 같은 런타임 오류가 사실상 타입 오류이며, TypeScript의 엄격한 설정(예: Null Safety)을 통해 이러한 유형의 버그를 컴파일 시점에 방지할 수 있음을 역설했습니다. 많은 프로그램 불변성을 타입 시스템이 확인할 수 있는 ‘일관성 문제’로 전환할 수 있다는 통찰을 공유했습니다. -
구성적 vs. 예측적 데이터: 데이터의 ‘구성적(constructive)’ 안전성(설계를 통한 보장)과 ‘예측적(predicative)’ 안전성(검증을 통한 보장) 개념을 소개하며, 타입 시스템이 전자에 기여하고 테스트는 후자에 기여한다고 설명했습니다. 이 두 가지 접근 방식은 상호 보완적이며, 문제 해결에 있어 유연한 전략을 제공한다고 강조했습니다.