기획명세서(2)
-
TDD 스터디 회고: 에러 핸들링의 책임과 TDD의 본질
안녕하세요, 저는 현재 TDD 스터디를 진행하고 있는 개발자입니다. 오늘은 이번 주 스터디를 하면서 고민했던 내용들을 여러분과 공유하고자 합니다.1. 에러 핸들링도 하나의 '책임' 이다이번 주에 저번처럼 기획을 기능 명세서로 만든 후,기능 명세서에서 명시한 Exception을 어느 계층에서 던져야 할지 고민이 되더라고요.이전까지는 Controller에서 DTO를 바인딩할 때 @Valid로 모든 검증을 처리했었거든요.필드가 유효하지 않은 값이 있다면, 서비스 로직까지 아얘 오면 안된다고 생각했기 때문입니다.서비스 계층은 비즈니스 로직을 책임지는 계층이지, 값의 유효성에 대한 검증의 책임은 컨트롤러에 있다고 생각하기 때문입니다.그래서 위 카테고리 수정 명세서를 예시로 들어보자면,'name'으로 빈 값이 들어..
2024.05.05 -
TDD 스터디 주간 회고 (4/22 ~ 4/28)
저희 팀은 이미 한 번 리뷰를 해본 적이 있지만,제대로 된 주간 리뷰는 이번이 처음이라 이렇게 글을 남기게 되었어요.스터디 진행 방식저희 팀의 스터디 진행 방식은 다음과 같습니다.1. 박우빈 님의 강의를 정해진 주차까지 듣습니다.2. 팀원들과 회의를 통해 기획명세서를 도출합니다. 이때 GPT에게 회사에서 주는 것처럼 해달라고 요청합니다.3. 기획명세서를 토대로 TDD를 진행합니다. 예전에 TDD를 할 때는 Red, Blue, Green 만 지키다 보니, 본질적인 것은 이게 아니라는 생각이 들었습니다.그래서 저희 팀은 스터디 내용 중에 명세서를 열어보는 것을 가장 중요하게 여기고 있습니다.TDD의 핵심은 명세서를 열어보고 해체하는 과정이라고 생각했어요.4. 서로의 코드와 테스트 코드를 화면에서 보고 리뷰합..
2024.05.01