3 주간의 대작업 후 솔직한 회고록

참 익스트림하게 하고나니, 꼭 회고를 하고 싶었다.느낀게 참 많았었다.뭘 뼈저리게 느꼈을까? ## 1. 기획의 A-Z 까지, 내 스스로가 빠진 게 없는 지 체크하기느낌점이 참 많았던 영역이다. 사실 이번에 큰일이 날뻔한 건 사수 때문이었다고도 생각했다.업무가 겹치다 보니, 사수가 계속 옆에서 " 이건 어떻게 됐냐, 왜 안 됐냐?" 등의 마이크로 매니징이 있었기 때문에 마지막에 문제 없이 일을 마무리 할 수 있었다.마이크로 매니징을 당하다(?) 보면 기분이 나기도 했었다. 상대에 대한 짜증보다도, 내가 부주의해서 일을 제대로 하지 못했을 때 나에 대한 자책이 섞인 짜증이었다.그래도 계속 해내다가, 일주일 전에 내가 전체 업무의 큰 부분을 고려하지 못했다는 걸 알게되었다. 이번에도 마이크로 매니징을 통해서...

안녕하세요, 저는 현재 TDD 스터디를 진행하고 있는 코랩입니다.이번 주 TDD 스터디를 하면서 배운 내용들을 여러분과 공유하고자 합니다.이번 주 작업 내용저희 팀은 이번 주에 6, 7장 강의를 수강하고,controller 테스트 코드를 작성하며, 서로의 코드를 리뷰하는 시간을 가졌습니다.이번 주에는 강의와 코드 리뷰를 통해 많은 것을 배울 수 있었습니다.강의에서 배운 내용1. 각 테스트 별 given, fixture를 @BeforeEach로 빼지 말자!각 테스트는 독립적으로 실행되어야 하므로, given과 fixture를 @BeforeEach로 분리하는 것은 좋지 않습니다.테스트 코드를 작성할 때, 특히 학습용으로 할 때는 비즈니스를 간단하게 가져가다 보니, given 절에서 반복이 자주 일어납니다. ..

안녕하세요, 저는 현재 TDD 스터디를 진행하고 있는 개발자입니다. 오늘은 이번 주 스터디를 하면서 고민했던 내용들을 여러분과 공유하고자 합니다.1. 에러 핸들링도 하나의 '책임' 이다이번 주에 저번처럼 기획을 기능 명세서로 만든 후,기능 명세서에서 명시한 Exception을 어느 계층에서 던져야 할지 고민이 되더라고요.이전까지는 Controller에서 DTO를 바인딩할 때 @Valid로 모든 검증을 처리했었거든요.필드가 유효하지 않은 값이 있다면, 서비스 로직까지 아얘 오면 안된다고 생각했기 때문입니다.서비스 계층은 비즈니스 로직을 책임지는 계층이지, 값의 유효성에 대한 검증의 책임은 컨트롤러에 있다고 생각하기 때문입니다.그래서 위 카테고리 수정 명세서를 예시로 들어보자면,'name'으로 빈 값이 들어..

저희 팀은 이미 한 번 리뷰를 해본 적이 있지만,제대로 된 주간 리뷰는 이번이 처음이라 이렇게 글을 남기게 되었어요.스터디 진행 방식저희 팀의 스터디 진행 방식은 다음과 같습니다.1. 박우빈 님의 강의를 정해진 주차까지 듣습니다.2. 팀원들과 회의를 통해 기획명세서를 도출합니다. 이때 GPT에게 회사에서 주는 것처럼 해달라고 요청합니다.3. 기획명세서를 토대로 TDD를 진행합니다. 예전에 TDD를 할 때는 Red, Blue, Green 만 지키다 보니, 본질적인 것은 이게 아니라는 생각이 들었습니다.그래서 저희 팀은 스터디 내용 중에 명세서를 열어보는 것을 가장 중요하게 여기고 있습니다.TDD의 핵심은 명세서를 열어보고 해체하는 과정이라고 생각했어요.4. 서로의 코드와 테스트 코드를 화면에서 보고 리뷰합..