prestudy-framework-spring

사전스터디 프레임워크 스프링

스터디 가이드

• 1주차 : 프로젝트 테크스펙 작성
• 2-4주차 : 요구사항을 바탕으로 기능 구현
• 5주차 : 회고 (팀 또는 개인)

참고 자료

문서화의 중요성

Tech Spec 작성

💡 ”기술적으로 더 나은 방향으로 갈 수 있게 동료와 함께 검증하기”

구현해야 하는 기능에 대한 논의가 충분히 이루어지고, 사용자 흐름에 대한 화면 정의를 구체화하면 개발자는 테크 스펙을 작성합니다.
테크 스펙은 개발자가 기능을 구현하기 전에 어떤 방식으로 구현할 것인지 작성한 문서인데요. 작업 전 문서를 작성함으로써 다음과 같은 효과를 얻습니다.

• 프로젝트가 잘못된 방향으로 흘러가는 것을 막아줍니다.
• 동료 작업자도 비슷한 수준의 맥락을 가질 수 있게 됩니다.
• 기술적으로 타당한지 미리 검토하고 오버 엔지니어링을 막을 수 있습니다.

[예시]

뱅크샐러드의 특별한 스펙, 테크스펙 👉 링크
Airbridge API 팀의 개발 프로세스 👉 링크

Tech Spec 양식

1. 프로젝트 요약 (Summary)
   누가/무엇을/언제/어디서/왜 를 세 줄 내외로 간단 명료하게

2. 목표 (Goals)
   예상 결과들을 Bullet Point 형태로 나열합니다. 이 목표들과 측정 가능한 임팩트들을 이용해 추후 이 프로젝트의 성공 여부를 평가합니다.

3. 계획 (Plan)
   테크 스펙에서 가장 긴 파트 입니다. 준비한 모든 리서치, 준비 내용들을 여기에 씁니다. 어떻게 기술적, 엔지니어링적으로 접근할지 상세히 묘사합니다.

   만약 어떤 부분을 어떻게 할지 확실히 결정하지 못한 상태라면 어떤 것들을 고려하고 있는지 목록화해서 적습니다.
   그렇게 하면 이 문서 리뷰어들이 올바른 결정을 내리도록 도움을 주게 됩니다.

   얼마나 기술적으로 깊게 써야 하는지는 이 테크 스펙의 목적과 독자들에 따라 정합니다. 작성자는 생산적인 제안을 받을 수 있도록 충분히 상세하게 계획을 적습니다.

   여기는 어떻게 프로젝트가 다른 시스템들과 상호작용하는지 그림이나 다이어그램을 포함하기 좋은 지점입니다.
   사용자와 시스템 간의 시퀀스 다이어그램, 서비스와 API 간의 데이터 흐름 다이어그램, 데이터베이스 ERD 등 다 좋습니다.

   이 테크 스펙이 로우 레벨까지 다뤄야 한다면 HTTP 응답 코드, JSON 요청 / 응답 포맷, 에러 명세 등까지 모두 다뤄져야 합니다.

4. 마일스톤 (Milestones)
   프로젝트를 제 시간에 맞추기 위해 테크 스펙의 내용을 바탕으로 추정한 마일스톤을 공유합니다.
   실험 계획, 배포 날짜를 포함해 최대한 자세히 적습니다.

Spring 과제

목표

• Spring Boot를 기반으로 CRUD(Create, Read, Update, Delete) 기능이 포함된 REST API를 만들 수 있어요.
• 인증/인가를 이해하고 JWT를 활용하여 게시글을 처리할 수 있어요.
• JPA 연관관계를 이해하고 회원과 게시글을 구현할 수 있어요.

요구사항 - 필수

API 명세서 작성, CRUD 구현

1. Use Case 작성

   • 손으로 작성 가능

2. 전체 게시글 목록 조회 API

   • 제목, 작성자명, 작성 내용, 작성 날짜를 조회하기
   • 작성 날짜 기준 내림차순으로 정렬

3. 게시글 작성 API

   • 제목, 작성자명, 비밀번호, 작성 내용을 저장
   • 저장된 게시글을 클라이언트 반환

4. 선택한 게시글 조회 API

   • 선택한 게시글의 제목, 작성자명, 작성 날짜, 작성 내용을 조회하기
   • 검색 기능 아님, 간단한 게시글 조회만 구현

5. 선택한 게시글 수정 API

   • 수정을 요청할 때 수정할 데이터와 비밀번호를 같이 보내서 서버에서 비밀번호 일치 여부 확인
   • 제목, 작성자명, 작성 내용을 수정하고 수정된 게시글을 클라이언트 반환

6. 선택한 게시글 삭제 API

   • 삭제를 요청할 때 비밀번호를 같이 보내서 서버에서 비밀번호 일치 여부를 확인
   • 선택한 게시글을 삭제하고 클라이언트로 성공했다는 표시 반환

[아래 질문 고민]

1. 수정, 삭제 API의 request를 어떤 방식으로 사용하셨나요? (param, query, body)
2. 어떤 상황에 어떤 방식의 request를 써야하나요?
3. RESTful한 API를 설계했나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?
4. 적절한 관심사 분리를 적용하였나요? (Controller, Repository, Service)
5. API 명세서 작성 가이드라인을 검색하여 직접 작성한 API 명세서와 비교해보세요!

---

AWS 배포, 회원가입/로그인

1. EC2 배포

   • 배포 후 ip 제출
   • 도메인 주소 연결도 가능

2. 회원가입 API

   • username, password 클라이언트에서 전달 받음
   • username은 최소 4자 이상, 10자 이하이며 알파벳 소문자, 숫자로 구성되어야한다.
   • password는 최소 8자 이상, 15자 이하이며 알파벳 대소문자 숫자 구성되어야한다.
   • DB에 중복된 username이 없다면 회원을 저장하고 클라이언트로 성공했다는 메시지, 상태코드 반환

3. 로그인 API

   • username, password 클라이언트에서 전달받기
   • DB에서 username을 사용하여 저장된 회원의 유무를 확인하고 있다면 password 비교하기
   • 로그인 성공 시, 로그인에 성공한 유저의 정보와 JWT를 활용하여 토큰을 발급하고, 발급한 토큰을 Header에 추가하고 성공했다는 메시지, 상태코드와 함께 클라이언트에 반환

[아래 질문 고민]

1. 처음 설계한 API 명세서에 변경사항이 있었나요? 변경 되었다면 어떤 점 때문 일까요? 첫 설계의 중요성에 대해 작성해 주세요!
2. ERD를 먼저 설계한 후 Entity를 개발했을 때 어떤 점이 도움이 되셨나요?
3. JWT를 사용하여 인증/인가를 구현 했을 때의 장점은 무엇일까요?
4. 반대로 JWT를 사용한 인증/인가의 한계점은 무엇일까요?
5. 만약 댓글 기능이 있는 블로그에서 댓글이 달려있는 게시글을 삭제하려고 한다면 무슨 문제가 발생할까요? Database 테이블 관점에서 해결방법이 무엇일까요?
6. IoC / DI 에 대해 간략하게 설명해 주세요!

요구사항 - 선택

• 아래 추가 요구사항에 맞게 ERD 수정 및 API 명세 변경할 것 ‼

추가 요구사항

1. 패스워드에 특수문자 추가하기
2. 회원 권한 부여하기 (ADMIN, USER) - ADMIN 회원은 모든 게시글,댓글 수정/삭제 가능
3. 댓글 작성 API
   • 토큰을 검사하여, 유효한 토큰일 경우에만 댓글 작성 가능
   • 선택한 게시글의 DB 저장 유무를 확인하기
   • 선택한 게시글이 있다면 댓글을 등록하고 등록된 댓글 반환하기
4. 댓글 수정 API
   • 토큰을 검사한 후, 유효한 토큰이면서 해당 사용자가 작성한 댓글만 수정 가능
   • 선택한 댓글의 DB 저장 유무를 확인하기
   • 선택한 댓글이 있다면 댓글 수정하고 수정된 댓글 반환하기
5. 댓글 삭제 API
   • 토큰을 검사한 후, 유효한 토큰이면서 해당 사용자가 작성한 댓글만 삭제 가능
   • 선택한 댓글의 DB 저장 유무를 확인하기
   • 선택한 댓글이 있다면 댓글 삭제하고 Client 로 성공했다는 메시지, 상태코드 반환하기
6. 예외 처리
   • 토큰이 필요한 API 요청에서 토큰을 전달하지 않았거나 정상 토큰이 아닐 때는 "토큰이 유효하지 않습니다." 라는 에러메시지와 statusCode: 400을 Client에 반환하기
   • 토큰이 있고, 유효한 토큰이지만 해당 사용자가 작성한 게시글/댓글이 아닌 경우에는 “작성자만 삭제/수정할 수 있습니다.”라는 에러메시지와 statusCode: 400을 Client에 반환하기
   • DB에 이미 존재하는 username으로 회원가입을 요청한 경우 "중복된 username 입니다." 라는 에러메시지와 statusCode: 400을 Client에 반환하기
   • 로그인 시, 전달된 username과 password 중 맞지 않는 정보가 있다면 "회원을 찾을 수 없습니다."라는 에러메시지와 statusCode: 400을 Client에 반환하기

추가 요구사항에 의한 변경사항

1. 전체 게시글 목록 조회 API
   • 각각의 게시글에 등록된 모든 댓글을 게시글과 같이 Client에 반환하기
   • 댓글은 작성 날짜 기준 내림차순으로 정렬하기
2. 게시글 작성 API
   • 토큰을 검사하여, 유효한 토큰일 경우에만 게시글 작성 가능
3. 선택한 게시글 조회
   • 선택한 게시글에 등록된 모든 댓글을 선택한 게시글과 같이 Client에 반환하기
   • 댓글은 작성 날짜 기준 내림차순으로 정렬하기
4. 선택한 게시글 수정 API
   • 수정을 요청할 때 수정할 데이터와 비밀번호를 같이 보내서 서버에서 비밀번호 일치 여부를 확인
   • 토큰을 검사한 후, 유효한 토큰이면서 해당 사용자가 작성한 게시글만 수정 가능
5. 선택한 게시글 삭제 API
   • 삭제를 요청할 때 비밀번호를 같이 보내서 서버에서 비밀번호 일치 여부를 확인
   • 토큰을 검사한 후, 유효한 토큰이면서 해당 사용자가 작성한 게시글만 삭제 가능