codestates/safu-client

🧑🏻‍💻부트캠프 후기 공유사이트 SAFU!👩🏻‍💻 이미 부트캠프를 경험한 선배들의 솔직한 후기가 절실한 지금! 당신에게 가장 잘 맞는 부트캠프는 어디일까요?

safu-client's Issues

[Retrospect] 3&4주차 회고 박혜인

박혜인

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• GET mypage & edit UserInfo기능을 위한 코드를 작성했다.
• EditPW 구현 중이다.
• feature 브랜치를 main으로 PR했다(...).

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• 최초 코드 작성 이후, 클라이언트 파트와 소통하면서 더 꼼꼼히 코드를 작성해야겠다고 생각했다.
• 내가 왜 그랬을까

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• 다짐만 하지 말고 실제로 꼼꼼해지자..
• 그동안은 해당 api 담당 팀원과 일대일로 소통했는데, 팀 슬랙채널을 통해 모든 팀원의 의견을 듣는 일도 필요하다고 느꼈다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 코딩하기 전에 기능 flow를 더 구체적으로 적어봐야겠다.
• 슬랙채널을 더 활발히 활용해야겠다.

issue practice

연습

[Server]find pw/Find password

ISSUE

• Group: server
• Type: feature
• Detail: find pw/Find password

TODO

1. find pw/Find password
2. 전송 온 메일로 해당하는 비번 전달해주기

Estimated time

2h

Labels

• Estimated time: E: 2h
• Group : server
• Sprint: Sprint__1__
• Urgency: High

[Client] CSS 작업

ISSUE

• Group: client
• Type: feature
• Detail:Figma->CSS(속성 정리)

TODO

1. main
2. cardlist
3. nav / menu
4. mypage
5. sign up / log in
6. find id / pw

Estimated time

Pick one

3h

Labels

• Estimated time: E: 3h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Retrospect] 1주차 회고 - 문상현

문상현

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• 컴포넌트를 기준으로 세팅했어야 하는데 페이지 기준으로 생각해서 결국 세팅작업을 두번하게 만들었다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• 충분히 더 고민하고 이야기를 나누었으면 더 좋았을걸 하는 아쉬움이 있었다.

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• 먼저 떠오른 아이디어가 언제나 최선은 아니다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 어떤 작업이나 아이디어에 대해서 맹목적인 신뢰를 하지 말고 최선이 맞는지 다시한번 검토하는 습관을 들여야겠다.

[Server]main(logged in)/authorization

ISSUE

• Group: server
• Type: feature
• Detail: main(logged in)/authorization

TODO

1. main(logged in)/authorization

Estimated time

2.5h

Labels

• Estimated time: E: 2.5h
• Group : server
• Sprint: Sprint__1__
• Urgency: High

[Client] find id

ISSUE

• Group: client
• Type: feature
• Detail: find id 페이지 구현

TODO

1. 컴포넌트 구성
2. 해당 아이디 알림 창으로 알려주기
3. 알람창의 확인 버튼 클릭-> redirect -> login 페이지
   4. [ ] 알람창 modal로 구현-> Advanced

Estimated time

Pick one

1.5h

Labels

• Estimated time: E: 1.5h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Client] sign up

ISSUE

• Group: client
• Type: feature
• Detail: sign up 페이지 구현

TODO

1. 회원가입 컴포넌트 구성
2. 아이디, 이메일 유효성 검사

Estimated time

Pick one

3h

Labels

• Estimated time: E: 3h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Client]social login

ISSUE

• Group: client
• Type: feature
• Detail: login 컴포넌트의 social login

TODO

1. Github 등록
2. social login uri로 갈 수 있도록 태그 안에 href
3. social login 후 추가 정보 요청=> 접근거부하는 식으로 해결

Estimated time

Pick one

3h

Labels

• Estimated time: E: 3h
• Group : client
• Sprint: Sprint_1__
• Urgency: High

[Client] client 기본 세팅

ISSUE

• Group: client
• Type: feature
• Detail: react create app, 전체 컴포넌트 구성

TODO

1. 맞출 기본 세팅 확인 - 다같이
2. react create app
3. 파일 구성 등 전체 컴포넌트 구성

Estimated time

Pick one

0.5h

Labels

• Estimated time: E: 0.5h
• Group : client
• Sprint: Sprint__1__
• Urgency: High

[Client] login

ISSUE

• Group: client
• Type: feature
• Detail: login 페이지 구현

TODO

1. login 컴포넌트 틀 잡기
2. 일반 로그인 구현

Estimated time

Pick one

2.5h

Labels

• Estimated time: E: 2.5h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Client] Routing 과 Redirecting 정리

ISSUE

• Group: client
• Type: fix
• Detail: 현재 라우팅 및 리다이렉팅이 너무 정신없게 되어있는 것 같아 이를 좀 정리하려고 합니다.

TODO

1. Nav.js 의 라우팅을 정리한다.
2. 모든 기능이 정상 라우팅 되는지 확인한다.
3. 모든 기능에서 정상 리다이렉팅이 되는지 확인한다.

Estimated time

Pick one

2h

Labels

• Estimated time: E: 2h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Client] main before login

ISSUE

• Group: client
• Type: feature
• Detail: main (before login) 구현

TODO

1. Main 컴포넌트 구성(menu 버튼 클릭시 해당 부트캠프 후기만 filtering(CSS))
2. Nav 컴포넌트 구성

Estimated time

Pick one

2.5h

Labels

• Estimated time: E: 2.5h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Client] main (logged in)

ISSUE

• Group: client
• Type: feature
• Detail: main (logged in) 페이지 구현

TODO

1. (새로운 페이지 아님) is Logged in 분기 추가
2. cardList 컴포넌트 생성

Estimated time

Pick one

1h

Labels

• Estimated time: E: 1h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Server]main/Get reviews

ISSUE

• Group: server
• Type: `feature
• Detail: main/Get reviews

TODO

1. main/Get reviews
2. active가 true 인 값만 가져오기

Estimated time

1.5h

Labels

• Estimated time: E: 1.5h
• Group : server
• Sprint: Sprint__1__
• Urgency: Middle

[Client]logout

ISSUE

• Group: client
• Type:feature
• Detail: logout 기능 구현

TODO

1. Nav 컴폰넌트에 logout 버튼 넣기
2. logout버튼 클릭시 세션 제거하기
3. 그 후 바로 login 안된 main 페이지로 리다이렉트 시키기

Estimated time

Pick one

2h

Labels

• Estimated time: E: 2h
• Group : client
• Sprint: Sprint__1__
• Urgency: High

[Client]find pw

ISSUE

• Group: client
• Type: feature
• Detail: find pw 페이지 구현

TODO

1. 컴포넌트 구성
2. 제출하기 -> 이메일,깃헙Id 서버로 넘겨주기
3. (이메일 전송됨)알람 -> 알람 확인 -> redirect -> login 페이지

Estimated time

Pick one

1.5h

Labels

• Estimated time: E: 1.5h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Server]sign up/POST signup

ISSUE

• Group: `server
• Type: feature
• Detail: POST signup /Check UserId

TODO

1. 회원가입 메소드
2. 아이디 유효성 메소드

Estimated time

1.5h

Labels

• Estimated time: E: 1.5h
• Group : server
• Sprint: Sprint__1__
• Urgency: Middle

[Server]new card/CREATE reviews

ISSUE

• Group: server
• Type: feature
• Detail: new card/CREATE reviews

TODO

1. CREATE reviews

Estimated time

1.5h

Labels

• Estimated time: E: 1.5h
• Group : server
• Sprint: Sprint__1__
• Urgency: Middle

[Server]info edit/PUT Edit userInfo

ISSUE

• Group: server
• Type: feature
• Detail: info edit/PUT Edit userInfo

TODO

1. PUT Edit userInfo

Estimated time

1h

Labels

• Estimated time: E: 1h
• Group : server
• Sprint: Sprint__1__
• Urgency: Middle

[Retrospect] 3&4주차 회고 문상현

문상현

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• API로 받아온 리스트를 필터링 하는 부분에 대해서 서버와의 통신없이 필터링 할 수 있는 방법이 있글거라 생각하고 코딩을 시도해보았다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• 될듯 안되고, 안되는 듯 될것만 같은.. 신기루를 쫓는 느낌이었다.

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• 서버와 클라이언트가 별개라고만 생각했는데 그런 사고의 코드에서는 아주 극명한 한계가 있었다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 서비스의 구현이 우선이어야 하고 그를 위한 서버와 클라이언트의 소통이 매우 중요한것 같다. 서버와 클라이언트를 독립적으로 생각하지 않고 소통하며 최선을 찾는 노력을 할것이다.

[Server]login/POST login

ISSUE

• Group: server
• Type: feature
• Detail: login/POST login

TODO

1. POST login
2. session 설정
3. 소셜 로그인 구현: 깃, 구글, (카카오)

Estimated time

1.5h

Labels

• Estimated time: E: 1.5h
• Group : server
• Sprint: Sprint__1__
• Urgency: High

[Client] login 관련 redirect

ISSUE

• Group: client
• Type: feature
• Detail: login 후 redirect 되는 모든 것

TODO

1. log in 버튼 누르면 -> redirect -> (logged) main 페이지
2. 회원이 아니신가요? Sign up 버튼 누르면 -> redirect -> Sign up 페이지
3. findId 버튼 누르면 -> redirect -> find Id 페이지
4. findPW 버튼 누르면 -> redirect -> find PW 페이지

Estimated time

Pick one

3h

Labels

• Estimated time: E: 3h
• Group : client
• Sprint: Sprint__1__
• Urgency: High

[Client] card edit

ISSUE

• Group: client
• Type: feature
• Detail: card edit 페이지 구현

TODO

1. 컴포넌트 구현
2. 수정하기 -> redirect -> mypage 페이지

Estimated time

Pick one

1.5h

Labels

• Estimated time: E: 1.5h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Retrospect] 3&4주차 회고 정현정

정현정

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• Mypage, Editinfo를 구현했다.
• 소셜로그인과 라우팅 부분 을 보충했다.
• IAM 생성부터 배포를 진행했다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• DB스키마에 대한 고민을 충분히 했으면 좋았을 텐데
• 배포를 수시로 해서 바로바로 확인을 했었어야했는데!

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• SR때 고민을 충~~분히 하고 다 문서화를 해야겠다.
• 코드리뷰와 동시에 코드리뷰 수정요청 사항이 마무리되면 배포를 바로 해서 확인해야겠다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 일단 오늘 배포환경에서 실행되는 것을 로컬 환경과 동일하게 맞춰놓아야 겠다.

[Client] my page

ISSUE

• Group: client
• Type: feature
• Detail: my page 페이지 구현

TODO

1. 컴포넌트 구현
2. API로 사용자 정보 불러와서 이메일, githubID 랜더링
3. editInfo 구현하고 -> 개인정보수정 버튼 클릭시 -> Editinfo로 리다이렉트

Estimated time

Pick one

1.5h

Labels

• Estimated time: E: 1h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Retrospect] 1주차 회고 - 박혜인

박혜인

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• 협업을 위한 깃 플로우를 연습했다.
• 서버 부분의 회원가입 기능을 위한 코드를 작성했다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• 공부해야 할 영역이 더 넓어지고 있고, 그만큼 작은 부분을 꼼꼼히 신경써야겠다고 느꼈다.

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• 모든 작업을 작은 단위로 나누어 정리하고, 단계별로 보완점 등을 꼭 기록한다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 이슈 구현이 끝날 때마다 특이점을 팀원들과 공유하고 블로깅해야겠다. 그리고 작은 의문점도 그냥 지나치지 말고 스스로 답을 정리해보도록 한다.

[Server]DB 기본 세팅

ISSUE

• Group: server
• Type: bug, feature, delete
• Detail: DB 기본 세팅

TODO

1. DB 기본 세팅
2. sequelize model 생성

Estimated time

1.5h

Labels

• Estimated time: E: 1.5h
• Group : server
• Sprint: Sprint__1__
• Urgency: High

[Server]Post logout/sign out

ISSUE

• Group: server
• Type: feature
• Detail: Post logout/sign out

TODO

1. Post logout
2. sign out
3. Job3

Estimated time

Pick one

1.5h

Labels

• Estimated time: E: 1.5h
• Group : server
• Sprint: Sprint__1__
• Urgency: Middle

[Server]card edit/Edit reviews/Delete reviews

ISSUE

• Group: server
• Type: feature
• Detail: card edit/Edit reviews/Delete reviews

TODO

1. Edit reviews
2. Delete reviews

Estimated time

1.5h

Labels

• Estimated time: E: 1.5h
• Group :server
• Sprint: Sprint__1__
• Urgency: Middle

security

ISSUE

• Group: client,
• Type: feature
• Detail: 개인정보 수정에서 입력한 비번이 hashing되어 전달됩니다.
  codestates/SAFU-server#102 의 4번 사항을 확인해주세요.

TODO

1. 개인정보 수정에서 입력한 비번이 hashing되어 전달

Estimated time

Pick one

1h

Labels

• Estimated time: E: 1h
• Group : client
• Sprint: Sprint__1__
• Urgency: High

[Client] sign up 후 redirect

ISSUE

• Group: client
• Type: feature
• Detail: signup 후 login 페이지로 redirect되는 것

TODO

1. signup 후 login 페이지로 redirect

Estimated time

Pick one

2h

Labels

• Estimated time: E: 2h
• Group : client
• Sprint: Sprint__1__
• Urgency: High

[Server]my page/Get userReview/GET userInfo

ISSUE

• Group: server
• Type: feature
• Detail: my page/Get userReview/GET userInfo

TODO

1. Get userReview
2. GET userInfo

Estimated time

1h

Labels

• Estimated time: E: 1h
• Group : server
• Sprint: Sprint__1__
• Urgency: Middle

[Server]find id/Find userId

ISSUE

• Group: server
• Type: feature
• Detail: find id/Find userId

TODO

1. find id/Find userId

Estimated time

1.5h

Labels

• Estimated time: E: 1.5h
• Group : server
• Sprint: Sprint__1__
• Urgency: Middle

[Retrospect] 1주차 회고 - 정현정

정현정

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• signup 컴포넌트 구현과 login 컴포넌트 틀을 만들었다. conflict를 해결했다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• HTML의 태그간 차이를 좀 더 알아야 할 것 같다. conflict를 해결하는데 너무 힘들었다.

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• upstream merge과 conflict를 겪으면서 pull을 잊지말고 하는 것이 중요하다고 생각했다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 하기 전 merge된 것이 있나 확인하고, pull을 받아오고나서 진행해야겠고, HTML이라고 만만하게 생각하지 말아야겠다.

[Retrospect] 1주차 회고 - 송현주

이름 : 송현주

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• 서버를 구현하기 위해 필요한 모듈들을 설치한 후, 셋팅작업을 진행했다. 그리고 DB를 구축한 후
  가장 메인 페이지에서 모든 데이터를 받아올 수 있는 메소드를 구현했다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• 초기 세팅이 진짜 너무 매우 중요하구나를 느꼈다. 그리고 생각보다 나는 더디고 속도는 느리니까 조급함을 느끼게 되었다.

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• 실제로 완성한 코드는 적지만 교훈은 많이 얻었다....

1. 초기 세팅이 매우 중요하다...메인화면에서 받아오는 데이터는 두개의 foreign key(외래키)를 가지고 있는 테이블이라
   단순하게 get을 해오면 되는 것이 아니었다. 외래키를 제대로 셋팅하고, 그리고 진행을 했었어야 했는데,
   그래 이거면 되겠지하고 넘어갔다가 메인에서 get 메소드를 작성하다가 DB를 잘못 셋팅했음을 깨닫고 부랴부랴 고쳤다.
   이거 때문에 뒷단의 다른 서버 작업들이 진행이 늦어진 점에 너무 아쉽다 ㅠㅠ
2. 나는 생각한 것보다 더디고 느리지만 조급해하지말고 하나하나 꼼꼼히 해야함을 느꼈다.
   일단 구현하면 되지! 라는 생각을 버리고, 현재 구현해야 하는 기능과 필요한 것들을 공부하고 이해하면서 코드를 작성해야
   이후에 에러 발생에도 대처할 수 있고 코드가 더 복잡해지더라도 헷갈리지 않음을 느꼈다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 조금 느리지만 꼼꼼하게 코드를 작성해서 최대한 되돌아가서 코드를 수정하는 일이 없도록!!

[Client] new card

ISSUE

• Group: client
• Type: feature
• Detail: new card 페이지 구현

TODO

1. 컴포넌트 구현
2. 등록하기 -> redirect -> main 페이지

Estimated time

Pick one

1.5h

Labels

• Estimated time: E: 1.5h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Retrospect] 2주차 회고 박혜인

박혜인

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• 로그아웃 , 회원탈퇴 기능을 구현했다.
• 마이페이지를 불러오는 기능을 구현 중이다.
• branch 생성, push와 pull을 하는 과정에서 팀룰과 git flow를 지키는데 실수가 있었다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• 한 번 혼란에 빠지니 계속 당황하게 됐다.
• 작성한 코드가 프론트엔드와 함께 구현되는 걸 보니 체계적으로 프로젝트를 진행하고 있다는 기분이 들었다.

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• 습관에 기대지 말고 정신을 차려야한다(!!)
• '구상-코딩-구현'의 모든 과정에서 팀원과의 소통이 중요하다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 실수의 기록
  : 어떤 순서로 어떤 커맨드를 쳤는지, 어떤 코드를 어떻게 수정했었는지 실수하는 과정도 기록해야겠다.
  : 이때 검색한 키워드와 해당 내용을 적용한 결과도 함께 적어둘 필요가 있다.
• 최소 한 가지 이슈카드를 마무리하고 나면 연결된 클라이언트 코드도 꼭 리뷰하자.

[Retrospect] 2주차 회고 문상현

문상현

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• CSS가 거의 완성되었다! 이제 조금 더 시각적으로 완성된 모습으로 작업할 수 있어서 좋다.
• cardEdit 컴포넌트를 예정 시간내에 완료하지 못했다. CSS가 생각보다 오래걸렸다.
• 어쨌든 cardEdit이 완료되었는데 구조적인 이해를 잘못하고있었다.
• cardEdit.js를 Hooks의 활용을 통해 함수형 컴포넌트로 만들었다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• CSS가 적용되고 시각적으로 완성도가 높아져서 뿌-듯했다.
• 시간이 조금 모자라서 다음날 새벽까지 코딩을 했다. 처음써보는 useState()가 재미있어서 피곤함보다 뿌듯함이 더 컸다.
• cardEdit을 새로만들게 아니라 기존에 있던 컴포넌트를 활용하기로 되어있던 것을 놓치고 새로 만들었다. 순간 철렁했지만 이번 실수가 다행히도 다른 팀원에게 피해가 없는 부분이라 조금 위안이 된다. 제대로 숙지하지 못한 점이 다른 팀원들(특히 팀장님)에게 미안하고 나에게 조금 실망스....

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• 역시 보기 예쁜 떡이 먹기도 좋다.
• 새벽 코딩은 마약 같다.
• 새로운 영역은 언제나 짜릿하다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• figma도 gitbook도 wireframe도 잘 보면서 작업하고 있다고 생각했는데 정작 구조적인 큰 부분을 놓쳤다. 숲을 보면서 작업하는 프로다운 여유를 가질 수 있도록 노력해야겠다.
• 새벽 코딩은 역시 마약같다. 시간 분배를 잘해서 작업시간이 새벽타임으로 넘어가지 않게 주의해야겠다.

[Server]server 기본 세팅

ISSUE

• Group: server
• Type: feature
• Detail: server 기본 세팅

TODO

1. server 기본 세팅 (express)
2. 필요한 express 모듈 설치
3. 초기배포

Estimated time

2.5h

Labels

• Estimated time: E: 2.5h
• Group : server
• Sprint: Sprint__1__
• Urgency: High

[Restrospect]3&4주차 회고_송현주

이름 : 송현주

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• DB 수정 중
• 기존에는 회원탈퇴와 리뷰삭제 시에 모두 soft delete로 하기로 이야기했었다. 그러나 코드 진행 중에, 회원정보는 hard delete로
  리뷰는 soft delete로 하기로 합의 보았다. 따라서 DB에서 user 테이블과 외래키로 연결된 키값들을 SET NULL로 정보를 변경해주어야했다,
  이때 마이그레이션을 수정된 부분만 입력해서 수정해야 하는데, 계속 엎는 식으로 수정했다가 결국 마이그레이션 시 원했던 최신 데이터들이 실제 데이터베이스에 제대로 반영이 안되어 버렸다. 그리고 배포 후에도 문제가 발생해 버렸다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• 초반에...마이그레이션....잘할걸...ㅠㅠ 마이그레이션으로 수정할때도 잘할걸....

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• 마이그레이션으로 모델을 수정할 때, 꼼꼼하게 잘 진행해야 함을 느꼈다.
  기존에는 수정해야하는 데이터들이 그렇게 복잡하지 않아서 그냥 새로 엎는 식으로 했는데, 프로젝트 때 이렇게 하니까 결국 DB가 꼬여버렸다...

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 초기 DB 논의 꼼꼼하게! 그리고 코드 진행될때도 데이터 통신에 대해서 잘 고려하고 마이그레이션을 할 때, 수정해야 하는 부분,
  안해도 되는 부분에 대해서 꼼꼼하게 수정하고 넘어가자!
• 마이그레이션에 대해서도 일일이 리뷰를 진행하자
  (결국 지금 마이그레이션으로 기존 table all delete 하고 다시 하는중입니다..)

[Client] info edit

ISSUE

• Group: client
• Type: feature
• Detail: info edit 페이지 구현

TODO

1. 컴포넌트 구현
2. 수정하기 -> redirect -> mypage 페이지
3. 회원탈퇴 -> 회원을 탈퇴하시겠습니까 alert -> 안전하게 탈퇴처리되었습니다. alert -> redirect -> 로그인 전 main 페이지

Estimated time

Pick one

1.5h

Labels

• Estimated time: E: 1.5h
• Group : client
• Sprint: Sprint__1__
• Urgency: Middle

[Retrospect] 2주차 회고 정현정

이름

Fact (사실) : 주요 사건에서 내가 취한 행동을 객관적으로 서술한다

• Login, Findid, Findpw, Mypage, Editinfo 컴포넌트를 구현했다.
• 서버와 클라이언트 코드 리뷰를 했다.
• API 논의 결과를 정확하게 인지하지 못하고 있어서 재논의 요청을 2번이나 했다.

Feeling (느낌) : 그때 느꼈던 기분을 간략히 정리한다

• 논의 결과를 그때그때 메모해두거나 gitbook에 간략히라도 적어놓았으면 좋았을 텐데

Finding (교훈) : 사건에서 얻은 교훈을 적는다

• SR 때 깃북을 정말 꼼꼼히 적어야겠다.

깃북 작성시 희망사항 정리

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 문서를 업데이트 시켜서 혼란이 없도록 해야한다.

Future action(행동) : 그래서 내가 앞으로 취할 행동을 미래형으로 적는다

• 앞으로는 더욱 꼼꼼하게 챙기고, 확실한 커뮤니케이션을 해야겠다!