메인 프로젝트 회고

https://github.com/jerimy321/seb45_main_010

GitHub - jerimy321/seb45_main_010

 

 

* 가장 큰 후회점 => 소통과 계획

 

 

소통

1. 백엔드와의 소통 : 데이터테이블의 구조, 데이터를 주고받는 방식, 데이터의 이름설정 

2. 프론트와의 소통 : 데이터 흐름과 구조에 대한 논의가 부족했다. 전역 상태관리가 필요한지 여부 체크 X, 이에 따라 각각 따로 전역 상태관리를 하면서, 예기치 못한 이슈가 발생했을때 이를 다른 팀원과 공유해도 코드흐름을 이해하는데 어려움이 있다. 어떤 방식으로 코드를 전개하고 있고, custom-hook 이나, items 등의 재활용가능한 코드들에 대해서도 충분히 공유하지 못했다. 

 

계획 

1. 처음 플래닝을 할때, figma 같은 디자인적인 레이아웃도 중요하지만, 시스템적인 레이아웃도 중요했다. 그걸 바탕으로 서로 다른 사람들의 코드가 쌓이기 때문이다. 말로하면 너무 당연한 사실이지만, 백엔드와의 플래닝이 끝난 후엔 아무래도 디자인적으로 구성이 우선되어야 계획이 가능하다보니 디자인에 시간을 쓰게 되고, 이후 일정에 떠밀려 일단 코드를 쓰고 보자, 라는 상태가 됐다. 

 

* 얻은 것

전역상태관리에 대한 흐름이해. jwt 토큰의 방식.

서버와 데이터통신을 해보면서 어떤 방식으로 소통해야 하는지, 내가 어떤 요구를 해야하고, 백엔드의 요청에는 어떤 응답을 해야하는지.

코드를 짜는데 걸리는 시간에 대한 이해. 백엔드가 다른 기능을 요구할 때도 있다. 이때 생각해야 할 점은, 물론 가장 먼저 내가 그 기능을 구현할 수 있는가, 겠지만 계획된 일정이 있는데 그 기능이 "작동"하게 할 수있는지 여부다. 보기엔 어려운 기능이어도 코드가 만들어지다보면 컴포넌트 하나만 만들어서 연결해주면 되는 경우도 있고, 아주 쉬운 기능이라고 생각해 Ok 했는데, 데이터테이블이 다르다던가 해서 전역 상태를 따로 만들어야 하고, 컴포넌트도 여러 개 작성해야 하는 경우도 있다. 이에 대한 이해가 조금은 생겼다. 

시간관리. 매일 두번씩 회의를 하는데, 내가 맡은 부분이 아니면 상대적으로 잘 안듣게 됐다. 코드 짜는데 시간에 쫓기다 보니 초조한 마음에 전체적인 흐름을 파악하기보다 내가 맡은 부분 생각만 하고 있었던 탓이다. 내가 하루에 어느정도의 코드를 작성해서 기능하게 할 수 있는지에 대해 다시한번 겸허히 생각하게 된다. 특히 생각지못한 에러가 터지면 그거 보느라 하루 이틀 잡아먹고, 그래도 해결되지 않는 경우도 많다. 하지만 그럴때 다른 사람에게 도움을 요청하면 문제점을 생각보다 쉽게 발견할 수 있다. 하루종일 같은 것만 바라보기 때문에 맹점이 생겨버리는 것이다.