Validation 에 대해
지난 티타임에서 이번 과제에서 Validation을 하는 이유 중 하나가 “TypeScript를 배우기 전 TypeScript의 동작을 배우기 위한 전단계일 수도 있다.”라는 이야기를 했었는데요. 여러분들의 코드를 보았을 때 그 부분에 꽂히셔서 유효성 검사의 적정 범위(?) 수준(?)에 대해 혼란을 겪고 계신게 아닌가 싶은 생각이 들어요.
우선 유효성 검사를 얼마나 해야하나에 대한 정답은 없지만…
완벽하려고하기 보다 잘 하는 것에 초점을 맞추고 작성하면 좋을것 같다는 생각이에요. 완벽하면 좋지만 처음부터 완벽하게 하기는 쉽지 않기 때문에 타협해서 우선순위를 두고 그 우선순위에 맞춰 대응을 하는 거라고 생각하시면 될 것 같아요.
잘 하는 것의 의미는 여러가지가 있을 수 있는데 제가 생각하는 것들을 적어볼게요.
- 필수적인 검사만 실행
- 모든 입력과 값에 대해 과도한 검증을 적용하기 보다 실제로 필요한 핵심적인 검사에 집중해야해요.
- 예를들어 아래와 같이
state가 문자열인지만 확인하는 간단한 로직이면 충분할 때가 많습니다.
- 조금 더 유저 중심적으로 생각하면 좋을 것 같아요.
- 현재의 Validation들은 유저 중심적이기 보다 type이 뭔지? 알아내기 위한 로직에 가깝고, 올바르지 않은 type인 경우 에러 핸들링을 보면 "Nodes.js - setState 메서드에 전달된 isRoot 프로퍼티가 'Boolean type'이 아닙니다. 확인해주세요.”와 같이 개발자 중심의 에러메시지가 작성되어 있는 경우가 많아요.
- 유저입장에서는 저 에러메시지를 보고 어떤것을 해야할지? 그럼 내가 뭘 할 수 있는데?? 와 같은 생각이 들 것 같아요. 사용자가 이해하고 대응할 수 있는 방식으로 설계되면 좋을 것 같아요.-
- 에러 핸들링
- 위의 내용에 이어 어떤 에러가 발생했을 때, 기술적인 에러를 상세하게 설명하는 것 보다. 에러 페이지를 띄우거나 간단한 에러 메시지를 띄워 올바르게 재시도할 수 있도록 도와주면 좋을 것 같다고 생각해요. 그래서 에러 메시지 or 재시도 유도를 통해 적절히 대응할 수 있도록 해주는게 좋을 것 같아요.
- 실무에서의 유효성 검사
- 실무에서의 경험을 바탕으로 보았을 때, validation은 FE보다 BE에서 더 자세하게 체크하는 경우가 많은 것 같아요.
- 잘못된 데이터가 들어갔을 때 크리티컬한 이슈가 발생하는 쪽은 FE보단 BE이기 때문이기도 하고, 양쪽에서 모든 조건을 Validation해주면 좋지만 FE에서는 유저 플로우에 맞게 비즈니스 요구사항에 맞는지 정도만 체크를 하고 타입이나 여러 특수케이스는 서버에서 체크하는 경우가 많은 것 같아요.