일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Study
- 일상속귀한배움
- 개발자
- Object
- 객체지향의사실과오해
- 클린코드
- AWS
- 독후감
- typescript
- 자청
- nodejs
- 스터디
- Nestjs
- 세이노의가르침
- UNiQUE
- validator
- 조영호
- nodemailer
- googleapis
- 북스터디
- futureself
- OOP
- BOOK
- serverless
- 역행자
- Validation
- 부자아빠가난한아빠2
- PRISMA
- 오브젝트
- 퓨처셀프
- Today
- Total
목록Validation (2)
우당탕탕 우리네 개발생활
과 를 공부하면서 흥미로운 법칙을 알게 되었다. 바로 보이스카웃 규칙 이다. 캠핑장은 처음 왔을 때보다 더 깨끗하게 하고 떠나라 라는 원칙이는 리팩터링이라는 단어가 갖는 철학과 너무 잘 맞는다. 이전보다 더 깨끗이 정리한다는 의미는 먼지하나 없이 깔끔하게 정리하는 것을 의미하지는 않는다. 상대적으로 조금 더 깔끔하면 된다. 이 법칙을 지닌 사람이 조직 내 많으면 많을수록 그 효과는 배가되지 않을까? 학교 수업이 끝난 후 모든 학생이 본인의 자리 주변만 정리해도 청소 당번이 따로 필요 없을 것이다.최근 레거시 코드에 피쳐를 추가할 일이 생겼다. 이미 시작도 전에 나는 법칙에 충만한 한 명의 보이스카웃일 준비를 마쳤다. 내 작업분을 테스트코드 작성과 더불어 마친 후 작업분 주변의 리팩터링 필요를 살핀 후 적..
백엔드 서버를 구성하면서 중요하게 생각하고 있는 것 중 하나는 정교한 validation입니다. 보통 저는 서버를 구축한 이후 API 문서를 작성합니다. 각 API 마다 Request에 필요한 파라미터들의 타입명시를 잘해놓고 테스트도 곧잘 합니다.(API문서에 명시한 스펙으로 말이죠.) 하지만 온갖 다양한 타입의 파라미터들을 Request에 담아 테스트를 하다 보면 예기치 않은 에러들을 마주하는 상황이 종종 생깁니다. 예기치 않은 에러라는 것은 문서에 명시하지 않은 에러코드를 나타낸다는 뜻이고 이는 해당 API를 사용하는 클라이언트 입장에서 핸들링할 수 없게 됩니다. 이로 인해 생길 수 있는 피해가 적다고 해도 이는 치명적인 상황으로 여기는 게 맞다고 생각합니다. 이런 생각으로 저는 validation적..