Q. 리팩터링을 통해 코드의 가독성을 높인 경험이 있으신가요?
이번 프로젝트를 진행하면서 리팩토링을 통해 코드의 가독성을 크게 향상시킨 경험이 있습니다. 예를들어 상수 변수들을 별도의 constants폴더에, 타입 지정은 별도의 types 폴더에 관리함으로써 코드의 일관성을 높였습니다. 또한 여러 페이지에서 공통으로 사용되는 컴포넌트를 별도로 추출하여 재사용성을 극대화했습니다. 결과적으로 코드의 가독성을 높이며, 유지보수 또한 용이하게 하였습니다.
Q. Next.js에서 라우트 핸들러를 사용했던 경험과 장단점에 대해 설명해 주세요.
현재 진행 중인 프로젝트에서 라우트 핸들러를 사용하여 청년 정책 api를 호출하는 기능을 구현하였습니다. 장점은 api 호출을 위한 별도의 주소를 설정함으로써 api 호출 로직이 명확하게 분리됩니다. 이로써 코드의 가독성을 높일 수 있으며 유지보수에도 용이해집니다.
그리고 라우트 핸들러를 통해 서버 측에서 데이터를 처리할 수 있어, 클라이언트측의 부담을 줄이고 성능을 향상시킬 수 있습니다.
반면, 여러개의 라우트 핸들러를 관리할 경우 각 핸들러 간의 의존성이나 상태 관리를 신경 써야 하므로 코드가 복잡해질 수 있습니다. 또한 라우트 핸들러의 성능이 중요한 경우 적절한 캐싱 전략을 고려할 필요가 있습니다.
꼬리질문. 라우트 핸들러 내에서 에러 처리는 어떻게 설계하셨나요?
에러를 try-catch로 잡고, 사용자에게는 적절한 상태 코드와 메시지를 반환했습니다
꼬리질문. API 호출 로직을 분리하면서 가장 어려웠던 점은 무엇이었나요?
처음에는 데이터가 클라이언트와 서버 중 어디에서 처리되어야 할지 명확히 구분하는 것이 어려웠습니다.
이를 해결하기 위해 데이터의 민감도와 처리 속도를 기준으로 서버에서 처리할 것과 클라이언트에서 처리할 것을 나누었습니다. 예를 들어, 사용자 인증과 같은 민감한 작업은 서버에서 처리하고, 단순한 UI 관련은 클라이언트에서 처리했습니다.
'개발 일기' 카테고리의 다른 글
2025-01-13(면접카타) (0) | 2025.01.13 |
---|---|
2025-01-07 (0) | 2025.01.07 |
2024-12-13(라이브러리vs프레임워크, next.js) (1) | 2024.12.13 |
2024-12-11(타입스크립트) (0) | 2024.12.11 |
2024-12-09(타입스크립트) (1) | 2024.12.09 |