10. Final Project 때는... 이렇게 더 보충해 봐야지

1) 이슈카드는 큰 덩어리로 분류하고, 각 덩어리 안에서는 기능 flow를 고려하여서 세분화 및 순서 부여를 시키는게 좋다. 

저번주만 하더라도 Client 쪽 issue card는 컴포넌트(솔직히 말하면 우린 SPA인데도 불구하고 페이지 기준)만을 기준으로 되어있었다. 그런데 리다이렉트가 빈번한 서비스이다보니 컴포넌트 간 구현 순서 역시 중요했다. 그래서 해당하는 것들을 더욱 세분화 하여서 순서대로 issue카드를 수정하게 되었다. 그래서, 

이렇게 하나로 퉁쳤던 issue 카드(login 기능 구현 으로 퉁쳤던 걸 )

-----------------------------------→

 

이렇게 세분화!

 

2) API 문서 작성을 할 때는 팀내 논의를 확실학게 한 후 정말정말정말 꼼꼼하게 작성 해야한다.

아래 항목들은 프로젝트를 하면서 이 점은 확실히 정하고 문서로 남겨두어야겠다는 생각을 한 것들이다. 이걸 잘 하지 못해서 매번 소문자/대문자 확인하느라, DB column명 확인하느라, 응답 형태가 어떻게 되는지 기다리느라 다시한번 커뮤니케이션을 해야하는 상황이 빈번했기 때문이다. 

1. API 네이밍:

[GET/POST/PUT/DELETE] [기능] 으로 깃북의 제목만 봐도 딱 무슨 역할을 하는 API를 알 수 있는게 편한 것 같다.

ex) GET Reviews/ POST Signup/ PUT Reviews/  DELETE Reviews

2. API 역할을 간략히 기술:

어디서 호출되는 API인지와 네이밍으로 알 수 없는 세부 논의 결과를 적어두면 이미 논의가 완료된 혼란이나 애매한 부분을 막을 수 있다. ex) GET Mypage는 클라이언트의 Mypage 컴포넌트에서 GET요청시 서버에서 세션에 저장된 특정 사용자의 전체 정보를  res하는 것으로 Client에서 따로 사용자 필터링을 하지 않아도 됩니다. 

3. API 엔드포인트:

분기 기준을 미리 정해서 이에 맞게 통일하는게 좋다. 

계층 구조를 나타낼 때는 /을 사용하고, filter가 필요하면 query를 적극적으로 활용하면 좋겠다.

우리 팀은 /[큰 DB명]/[API가 쓰이는 상위 컴포넌트명]/[API가 쓰이는 하위 컴포넌트명] 로 규칙을 정해서 사용하고 있다. 이때 소문자/대문자 쓰는걸 팀내에서 잘 통일해서 쓰자! 그렇지 않아서 findid인지 findId인지 눈을 크게 뜨고 봐야했다...

ex) /users/signup

/users/signup/checkid

/users/login

/users/login/findid

4. Request의 Form Data Parameter, Body Parameter 확실하게 하고 쓸 때 꼼꼼하게 숙지하고 쓰기!

이걸 클라이언트와 서버가 확실하게 숙지 하지 않으면 예를 들어 어느 한쪽에서는 useremail로 request를 주었는데, 한 쪽에서는 request에 email 정보가 잘 담겨왔나~ 라고 서로 다른 것을 주고 받고해서 undefined라는데요?! 라는 문제가 생길 수 있다. ( + 여기서도 이때 소문자/대문자 쓰는걸 팀내에서 잘 통일해서 쓰자! 그렇지 않아서 githubid인지 githubId인지 눈을 크게 뜨고 봐야했다...)
5. Response의 Status code와 json에 담겨오는 데이터의 형태를 확실하게 하고 쓸 때 꼼꼼하게 숙지하고 쓰기!

json에 담겨오는 데이터의 형태는 클라이언트가 어떻게 데이터를 검사하여 state변경을 해주고, 어떻게 랜더링 할지 정하는데 매우 중요하다. 서버파트와 클라이언트 파트가 동시작업이 이루어지려면 이 역시 사전에 정해지는게 좋을 것 같다. 그러나 하다보면 더 좋은 데이터 구조가 떠오르기도 하고, 변동사항이 많은 부분이기도 하다. 그럴 땐 논의 완료 후 빠르게 API 문서를 업데이트 시켜서 혼란이 없도록 해야한다. 

ex)

client에서 fetch로 데이터 받아올 때, 참고하면 좋을 듯하여, 서버에서 보이는 데이터 형태 공유합니다!
{
id: 3,
users_id: 13,
bootcamp_id: 5,
githublink: "https://github.com/codestates/SAFU-server.git",
price: "비쌈",
level: "어려움",
recommend: "추천",
curriculum: "어려움",
comment: "자기주도 학습!!!!중심이다",
active: true,
createdAt: "2020-10-17T13:00:04.000Z",
updatedAt: "2020-10-17T13:00:04.000Z",
useremail: {
   email: "hjhjhj93@naver.com"
    },
bootcampname: {
     name: "codestates"
    }
},

3) 팀 내 공용 이메일

findPw기능이 있는 이상 이메일로 비밀번호을 보내주거나 비밀번호 변경가능 링크를 보내주어야 한다. 이때 발신자 로 사용할 공용계정을 만드는게 좋을 것이다. 

 

4) AWS 공용계정

위에서 만든 공용 이메일로 AWS 공용계정 가입하기

프리티어.. 너무 적어

 

5) 가장 먼저 배포하기! +IAM 에서 권한 설정 및 CLI 설정

특히 RDS! 계속 팀원 개인의 mysql을 사용하니까 테스트케이스가 각자 달라서 너무 불편했다.

 https://react-etc.vlpt.us/08.deploy-s3.html

리액트 앱 AWS S3, CloudFront 에 배포하기 · GitBook

6) 회의록 작성하기!