[KPT] 김지영 2021-10-15

### Keep (유지할 항목)
- 반복적으로 사용되는 기능을 컴포넌트로 만들면 페이지 랜더링에 컴포넌트와 props만 작성하기만 하면 되기 때문에 편했다.
- 각자 분업이 확실히 되어 협업일지라도 크게 상의할 것 없이 할 일을 하면 완성할 수 있던 것이 좋았다.
- 개인 작업을 새벽까지도 했기 때문에 오전에 코드를 정리하는 시간을 갖고 오후에 코드리뷰 시간을 갖는 것이 좋았다.
- 코드리뷰 시간 외에도 필요할 때마다 소통하여 상황을 주고 받은 덕에 전체 상황을 파악할 수 있어서 좋았다.
- 사전에 팀 차원에서 작성한 와이어 프레임, API문서가 프로젝트 내내 유용한 참고 문서가 되었다.

### Problem (문제라고 생각하는 항목)
- 단순히 반복적으로 사용되는 것 같아도 여러 페이지에 사용되며 다양한 조건이 필요한 작업을 하나의 컴포넌트로 해결하려 하니 중간에 코드가 복잡해지고 로직도 조금 꼬여서 거의 새로 쓰는 정도로 전면 수정했다.
- 클라이언트가 현재 배포되어 있는 aws와 연동이 어떻게 되는지 제대로 몰랐기 때문에 클라이언트에서 서버로 보내는 요청이 잘못되어 많은 시간을 허비했다.
- 상태 변수를 전부 useEffect에 의존해서 컴포넌트에 내려주고 올려주고를 반복하니 전달해야 하는 prop가 점점 늘어났다. 각 컴포넌트에, 그 많은 매개 변수에 전달 인자 하나 잘못 전달하면 실행에 실패하게 된다.
- CSS를 할 때 디자인부터 막혔다. 생각한 것을 기능 구현으로 옮기는 것도 문제였지만 어떤 기능을 하게 할 것인지, 디자인은 어떻게 할 것인지 하는 목표 설정이 흐릿했기 때문에 CSS 구현이 더 어려워졌다.
- 잠을 제대로 좀 자가면서 해야한다. 피곤하니까 생각도 느리고 넋을 조금 놓으면서 했던 거 같다.

### Try (Action Items)
- 문제였던 것들 중 기능과 CSS 둘의 공통 문제점은 흐릿한 사전 계획이다. 기능 구현 시에는 팀이 다 같이 작성한 와이어 프레임에 만족할 것이 아니라, 분업 후 내게 주어진 것에 대해 더 세세하게 어떤 방식으로 기능을 구현할지 work flow와 와이어 프레임을 작성한다면 시간 낭비가 줄을 것 같다.
- 클라이언트와 배포된 서버가 어떻게 연동 되는지 개념을 잡아야 한다.
- 상태 변수 관리를 리덕스로 한다면 프론트 전체의 작업이 편해질 것 같다.