[KPT] 2주차 Front End 임예지

### Keep (유지할 항목)
- 이슈 사항 발생 시 모두에게 공유하여 빠른 해결을 도모하고, 코드의 conflict을 최소화한 것이다. 본인이 작성한 코드가 다른 개발자의 코드에 영향을 미치는 것이 있다면 메신저로 빠르게 공유하여, 다음 merge에서 conflict 발생을 최소화할 수 있었다.
- 상황에 따라 merge 순서를 정하는 것이다. merge를 하다보면 수정한 코드임에도 merge 과정에서 reset되는 경우가 발생했다. 때문에 동일 파일에서 작업을 한 경우 등등 상황에 따라 merge 순서를 결정하는 것 또한 좋았던 것 같다.
- merge할 때, 팀원 모두가 모여서 진행하는 것이다. 모든 팀원이 모여 merge를 진행하다보니 각각의 개발자가 의도한 코드를 빠르게 파악할 수 있었고, merge 이후 발생하는 conflict도 큰 이슈없이 해결할 수 있었다.
- 시간에 대한 약속이다. 공식 회의 시간은 오전 9시, 오후 5시로 하루에 2번 회의시간을 가진다. 다행히 팀원 모두가 회의시간을 준수한 덕분에 회의를 원활히 진행할 수 있었다.

### Problem (문제라고 생각하는 항목)
- 전체적인 UI를 기획하고 코드를 작성하는 것이 필요한 것 같다. first project에서는 전체적인 UI를 확실히 기획하고 진행하지 않았다. 그 결과 페이지별로 각 개발자의 디자인 스타일이 반영되어 있어, 디자인의 통일감이 떨어진다는 아쉬움이 남는다.
- 사용 스택의 장점을 활용할 수 있는 코드 작성이 필요하다. 예를 들면, 공통으로 사용되는 styled component를 생성하여 코드 작성의 효율성을 높이는 것이다.
- 1차 기능 구현 완성기간과 최종 마감기간 사이에 넉넉한 시간을 두는 것이 필요한 것 같다. 1차 기능구현 완성에서 생각보다 많은 에러를 발견했고, 발표를 준비하는 과정에서도 아쉬운 점들이 발견되기도 했다. 다음에는 1차 기능구현과 마감기간 사이의 시간을 넉넉하게 두어 에러사항을 면밀히 살펴볼 수 있는 시간이 있으면 좋을 것 같다.
- 서비스가 실제 런칭된다는 가정과 함께 세세한 부분을 고려할 필요도 있는 것 같다. 예를 들면, 네트워크 환경이 좋지 않은 지역에서 우리의 서비스를 이용한다면? 게시글 작성, 게시 도중에 서버에 문제가 생긴다면? 등등 실제 발생할 수 있는 부분들을 체크할 필요가 있다.

### Try (Action Items)
[ ] 2주차 프로젝트 기능 구현 점검 및 회고
[ ] 4주차 프로젝트 주제 고민
[ ] 4주차 프로젝트 스택 학습(redux, redux-persist 등)