[1차 협업프로젝트 TIL] 6일차 회고

 

6일차 진행기록 및 좋았던 점

 

오늘은 전날 수정사항을 다시 체크해보고, 내가 새로 만든 커스텀 radio 버튼 동작을 확인하여 PR했다.

 

또, 팀원분들이 모달을 적용해 보고, 특이사항이 없어서 이제 코드를 최적화해보려고 예정하고 있다.

 

오늘 데일리스크럼 시간에는 다음과 같은 사항을 공유했다.

• 현재 작업상황 및 예정된 작업 공유
• 최신 PR 공유 및 merge
• 작업내용 중 개선사항에 대한 의견 공유
• 토요일 데일리스크럼시간 결정

6일차를 진행하면서 내가 만든 모달, 기능들이 잘 작동하는 것 같아서 맡은 역할을 잘 수행하고 있다는 생각이 들었다.

 

또, 팀원들과 각자의 작업현황을 공유하면서 새로운 개선 아이디어들을 계속 만들어내고 있어서 프로젝트가 더 탄탄해지고 있다는 느낌도 들었다.

 

6일차에 새로 배운 점

 

💡 api에서 정상적으로 데이터를 받을 때, 에러를 받을 때를 모두 response만으로 반환하면, api 요청 컴포넌트에서 catch문으로 에러처리를 할 수 없다.

이 점은 좀 더 알아봐야겠지만, 오늘 에러처리에 대해 상당한 시간을 할애해서 알게 된 사실이다. 

 

나는 api 요청할 때는 아래처럼 했었다. (axios 사용)

const handleVote = async () => {
  try {
    투표로직 및 요청 
    
    if(response.status === 200) {
      200 수신 시 로직
    }
  } catch (error) {
    에러처리 로직
  }
};

 

그런데 이렇게 하니까 에러가 났을 때 이상하게 에러는 발생하는데 내가 봐왔던 에러처리가 제대로 동작하지 않았던 것이다.

 

그래서 아래처럼 수정해보았다.

const handleVote = async (e) => {
        투표 로직
        
        요청 
        
        if (response instanceof Error) {
            에러처리
        } else {
            200 수신 시 로직
        }
    };

 

이렇게 수정하니까 정상적인 에러처리가 되었다.

 

instanceof Error를 사용하면 반환된 내용이 Error일 때를 감지해준다고 한다.

 

진행하면서 부족하거나 개선이 필요한 점

 

💡 현업에 계신 분들은 자신이 만든 기능에 대한 의견이 들어오면 바로 반영하는지, 의견을 모아서 따로 그것에 대해 공유하는 시간을 가지는지 궁금하다.

왜냐면 지금 나는 의견이 들어오면 후자의 경우처럼 하고있다. 그런데 대면한 상황에서 바로 어떠한 답을 줘야 의사소통이 되기 때문에 미묘한 애로사항이 있다.

 

바로 반영하기엔 그렇게 하지 않은 분명한 이유가 있을 때는 해당사항에 대해 이야기하지만, 공감대가 형성되지 않는 경우라든지 적용하기에 애매한 경우 등 다양한 경우가 존재하기 때문에 개발업무에서 이러한 경우 대처하는 스킬 구사하는 방법이 아직 미숙하다.

 

경험을 쌓아가면서 터득해봐야겠다.

 

향후 프로젝트에 대해 기대되는 점이나 바라는 점

 

지금대로 잘 돼서 마무리되면 좋겠다.

 

내일부터는 발표 준비도 해야한다. 준비한대로 잘 해서 잘 전달됐으면 좋겠다.