🔒 [ SR 계획 단계에서 지적 받은 사항]
< Wiki >
1. 오프라인 모임이라는 키워드가 있었으면 좋겠다.
=> 가이드와 여행자들이 함께 여행하는 컨셉이 명시적으로 설명돼야 할 것 같다
- Home을 더 개조식으로 작성하고 서비스 소개와 기능 소개는 다르다는 것을 인지할 것
=> Bare Minimum 과 서비스 소개가 거의 다를 게 없다
=> 사용자의 측면에서 어떤 서비스를 누릴 수 있는지를 개조식으로 작성해야할 것 같다
< REST-API >
- guide_id 삭제는 path parameter 를 이용해 삭제해보는 방식도 있으니 한 번 고려해보길 바란다
=> 이 부분에 대해서는 저번에 의논하면서 나왔던 문제인 path 에 해당 id 값을 넣어도 괜찮은가, 이렇게 되면 URL 로 악성 유저가 게시글을 막 지울 수 있는 것은 아닌가에 대한 질문을 올렸습니다. 확인해보고 있는데 path parameter 사용을 하는 방향으로 가는 게 오히려 좋을 것 같습니다.
2. 201 CREATED 된 Body 안에 응답 바디를 작성할 것
=> MDN 문서에서도 지시하고 있는 부분
=> 모두 이렇게 구성해야한다는 것은 아니지만 POST 가 어떤 리소스에 영향을 주었는지 보다 명시적으로 설명할 수 있기에 그 부분을 작성해서 BODY 에 담아주면 좋을 것 같다
- REST API 추가적으로 작성할 때 에러를 어떻게 다루고 처리할 것인지 고려를 해볼 것. 여기서 에러가 난다면 어떤 에러가 날 것이고, 어떤 이유에서 발생한 것인지를 고려하며 적어두면 더욱 효과적이고 좋은 REST API 가 될 것
4. /signup/chek-id 말고 GET /signup 으로 가는 것은 어떤가?
=> 이 부분은 함께 모였을 때 수정했습니다.
5. 가이드 카드의 응답이 스키마 타입의 응답과 다른 경우 발견
=> 이 부분도 함께 모였을 때 수정했습니다.
< Front-End >
1. SVG 로 구현하는 애니메이션 Advanced 말고 Bare-minimum 으로 했으면 좋겠다
=> 만약 구현한다면 완성도가 훨씬 높은 렌더링 페이지가 될 것 같다
- 데이터 스키마에서 각 명칭이 조금 더 직관적었으면 좋겠다
속성
=> 1) state -> 고려중
=> 2) o_auth -> 고려중
테이블명
=> 1) guide -> guide_card 로 수정 완료
🔑 [ SR 을 보고 만족스럽다, 기대된다고 한 사항 ]
<만족 사항>
- 의사 결정 룰이 굉장히 자세하다
- 팀원들과 굉장히 세세하게 SR 기획을 짠 티가 많이 난다. 의사 소통을 열심히 하는 것 같아서 매우 보기 좋다.
- Dev-Log 작성하는 걸 봤다. 매우 좋다.
< 기대되는 기능 구현 >
- SVG 를 이용한 애니메이션 구현
- 인원 마감 기능 구현
start coding