클론코딩 마무리

항해를 시작한지 5주차가 지나면서 클론코딩까지 마무리가되었다. 확실히 미니프로젝트를 통해 한번 경험을해보니 어느정도 수월하게 진행됬다. 미니프로젝트간에 아쉬웠던 협업도구사용, api설계를 확실하게하고 진행하였고 부족한 인증관련부분도 전보단 자신감도생겼고 추가적인 챌린지로 소셜로그인도 구현했다.

협업을진행하면서 아쉬웠던점.

에러처리를위한 사전 약속 간과

그럼에도불구하고 api설계시 간과했던 부분이 또다시 발생했다... 그부분은 에러코드 합의(?) 부분인데 한가지예로는 이렇다.
프론트단에선 api요청을보내고 응답을받을떄 프로미스의 then,catch로 받아 정상적인 반응인지 에러가발생했는지를 구분했다. 그런데 등록되지않은 사용자가 로그인을 시도했을시 then으로 응답을 받아오고 응답중 메세지값이 '등록되지않은 회원입니다'라는 문구로 에러를 알려줬었다. 이는 우리가 에초에 에러가 발생하면 catch로 빠질것이라는 생각에서 벗어난 상태다. 그래서 프로젝트 진행중 서버쪽에 등록되지않은 회원이라면 400에러로 전송해줄것을 요청하여 catch로응답을 받아 에러를 처리할수있게 재설정 하였다.(다행히 서버쪽에서 400에러로 수정하는과정이 그렇게 어려운과정이 아니라고하셨다) 200으로 받았을떄 어떻게하면 프론트에서 에러를 처리할수있을까를 생각하다가 프로미스의 async await을 생각해봤다. 이는 미들웨어를 async함수로 설정하고 api요청을 받는 로직앞에 await를 붙여줌으로써 비동기인 서버요청이 받아올떄까지 잠시 멈췄다가 변수명 reslut로 응답값을 받아올수있다. 이렇게하게되면 받아온 result객체안에서 메세지를 확인하며 '등록되지않은 회원입니다'에해당하면(물론 fail이라는 상태도 함꼐 전송해주셨었다) if else문을 활용하여 사용자에게 적절한 메세지를 보여주고 처리하면된다. 여기서 async await의 활용과 어떤식으로 에러를 전달할지를 미리 사전에 약속을 해야 혼동이없을것이라는것을 배웠다.

배운점

렌더링 최적화에대해 생각해봐야된다는점

팀원분중 한분이 한 페이지에서 분류를위한 버튼을 누를떄마다 해당하는 버튼의키워드내용이 필터링되는 기능을 구현했었었다. 이떄 그 키워드 버튼을 누를떄마다 서버에 요청을 보내 해당하는 내용을 받을것인지, 아니면 페이지에들어올떄만 최초로 데이터를받고 자체적으로 필터링을 하는 기능을 작성하여 분류를할지를 고민했었다. 이러한 부분들도 결국 api설계단계에서 짚고 넘어갔어야했다.

소셜로그인 작동방법

실생활에서 어플을 이용할떄 항상 마주쳤던 카카오로그인을 구현해보았다. 흐름을 이해하는데 집중했었고 코드적인부분에서는 아쉬운점이있지만( 리다이렉트경로에서 인가코드를 서버로보내기위해서 새로운 컴포넌트를 인위적으로 만든것, 미들웨어함수에서 histroy가 실행되지않는점..) 진행과정을 이해하는데는 충분했다.

그날그날 각자의 진행상황을 공유한점

아침마다 매일은아니지만 각자의 작업상황을 공유하는 시간을 가졌다. 약속을하고 진행한것은아니지만, 다음 프로젝트에는 매일 시작시간과 끝나는시간을 정해놓고 30분정도는 각자의 상황을 공유하는 시간을 가지면 전체적인상황을 공유하는데 좋을것같다.

에러처리

try cath문과 throw를통해 코드를작성하면서 에러가 발생할것같은 지점에서 원하는 에러문구를 만들어 어느부분에서 에러가 발생했는지 확인을할수있다는 사실을았다.( 아직 적용해보진않음)

다음프로젝트에 반영할 내용

일일 회고

시작할떄와 끝날떄 진행상황을 공유하는시간을 꼭 반영할 예정이다.

깃 커밋메세지 통일

커밋메세지를 통일하여 좀더 개발자스러운 자세를 갖출예정이다.

api설계시 에러코드 전달방식 상의

어떤식으로 에러처리를 넘겨받을것인지 상의할 예정이다.

개인공부시간 반영

시간이 긴 프로젝트인만큼 공식문서의 내용을 헷갈렸던 내용을 위주로 읽어볼 예정이다.