트러블 슈팅 기록
1. 첫 배너 스크롤 구현 단계
일단 isScrollDown hook을 구현한 뒤
스크롤을 내렸을 때 true, 올렸을 때는 false값을
배너 컴포넌트에게 주어 애니메이션을 구현했다.
그러다 성능 문제를 발견했는데,
매번 스크롤을 내릴 때마다 true 값을 배너 컴포넌트에게 주어
리렌더링이 잦아져 성능저하가 생긴 것이다.
그래서 2가지 방안을 세웠다.
첫째, banner 내부에서 스크롤을 반대방향으로 했을 때에만 스크롤 다운 이벤트를 발생시키기
useEffect(() => { let timer; if (isScrollDown && show) { clearTimeout(timer); timer = setTimeout(() => { setShow(false); }, 220); } if (!isScrollDown && !show) { clearTimeout(timer); setShow(true); } return () => {}; });
두번째, React.memo를 사용하여 같은 props값이 넘어 올때에는 리렌더링이 발생하지 않게 하기
이후 생각해보니 어차피 props값이 변경될 때에만 리렌더링이 된다면 굳이 첫번째 로직은 불필요하다고 생각이 든다.
→ 배운점
리액트 memo와, 리액트 내부에서 최적화를 위한 메서드들을 제공하는 것들에 대한 지식이 부족하다는 것을 인지했다. 앞으로 이 부분을 보완할 수 있는 공부를 더 해야할 것.
2. 무한스크롤 api 반복호출 작업
무한스크롤 로직상 새로운 데이터를 불러올 때
trigger 되는 dom에 계속 intersection이 잡혀서 리렌더링이 되기까지
api 호출이 되는 버그를 발견했다.
원래 내가 맡은 코드가 아니기 때문에, 오류해결을 돕기 위해 코드를 분석해보니
처음 무한스크롤을 위한 api로직을 실행한 후, observer을 건 dom을 해제하면 해결될 문제로 보였다.
리렌더링 이후 맨 마지막 card에게는 다시 observser가 걸리기 때문에 이상은 없어 보였다.
그리고 역시나 해당 문제가 해결이 되었다.
→ 배운점
문제가 생긴다면 먼저 버그를 재현을 한다,
그리고 어디서 문제가 생겼는지 알기 위해서, 변인 통제 를 할 필요를 느꼈다.
해서 콘솔를 찍어보면서, 어느 요소가 영향을 미치는지 파악을 했고,
Ref가 문제라는것을 알게 되었다.
즉, 어느요소가 어떤 영향을 끼치는지 파악을 하는 것이 버그를 잡는 방법중 하나라는 것을 알게 되었다.
KPT
Keep 가져갈 것들
“1시간내에 해결이 안되면 도움을 청하는 문화”
문제가 발생했을 때 또는 이해가 안되는 부분들이 있을 때,
1시간 동안 혼자서 해결이 되지 않는다면
팀원들에게 물어보는 문화는 좋은 문화인 듯 하다.
알려주면서 더 배우고, 또 모르는 부분들은 다른 팀원에게 배우면서
실력이 향상되는 경험을 여러번 했다.
“문제 발생시 즉시 공유하는 문화”
사람은 누구나 실수 할 수 있다.
다만 우리는 모든 실수로부터 배울 수 있는데, 실수를 숨기거나 공유를 하지 않으면
팀원간의 오해를 불러 일으킬 수도 있고, 때론 프로젝트 안에서 더 큰 문제를 발생시킬 수도 있다.
해서 문제가 발생 할 시 즉시 슬랙에 공유하는 문화는
팀원 개개인에게도 프로젝트에게도 효율적인 방법이었다.
“이슈를 열고 해당 이슈기반으로 브랜치를 하여서 개발하는 로직”
먼저 이슈를 봄으로써 현재 어떤 것들이 필요한지 알 수 있었고
해당 이슈번호로 브랜치를 생성하기 때문에
특정 문제에 대한 코드를 보고 싶다면 해당 번호로 만들어진 브랜치를 찾으면 되기에 간편했다.
“오픈 및 종료 스크럼”
처음 스크럼을 통해서 어떤 것들을 개발할 지 정하고, 개발 후에는 스크럼을 통해 마무리 하는 것이
서로의 진행 상황을 알 수 있었기 때문에 다음날 프로젝트를 진행할 때 원활히 시작할 수 있어서
공유차원에서는 나쁘지 않았다고 생각한다.
Problem
개인적으로, 프로젝트 마감시간이 다가올수록 코드리뷰가 더뎌졌다.
개인적으로 점점 처내야 할 일들이 많아지다 보니,
다른 것에 집중하느라 코드 리뷰를 제대로 하지 못하고 approve를 날리는 일들이 종종 생기게 되었다.
팀적으로, 각자가 컴포넌트를 나눠서 맡으면서 개발을 하게되었는데,
시작이 촉박하다보니 각자가 만난 문제 그리고 해결하는 방법들이 서로 공유가 잘 되지 않아서
나중에 소통이 까다로워지는 아쉬운 부분들이 있었다.
Try 시도 해볼것
테크 문서를 작성해볼 것.
이슈기반으로 작업을 작성하고 진행을 하는 것은 나쁘지 않았지만,
후에 다른 분들이 작성한 해당코드를 분석 할 때
팀원분들이 어떤 사고방식으로 해당문제를 해결했고 그걸 어떤 코드로 풀어 냈는지에 대해서
자세히는 알지 못하는 아쉬움이 있었다.
그래서 테크 문서를 작성해서
해당 컴포넌트를 어떻게 쪼개고,
어떤식으로 풀어갈지를 서로 글로써 공유한다면
잘하는 팀원들의 암묵지를 습득함으로써 팀 자체가 더 성장 할수 있지 않을까 기대한다
에러 및 문제 해결을 서로 발표하는 자리의 부족
이번 프로젝트는 2주라는 너무 촉박한 시간동안 진행되었기 때문에,
해당 부분을 서로 이야기 하는 시간이 부족했다고 든다.
이후에는 프로젝트를 하지 않더라도,
금요일 스크럼때나 한주 1번 또는 2주에 한번 정도는
자신이 공부하면서, 프로젝트를 하면서 겪었던 어려움,
그리고 그것을 어떻게 해결했는지 각자가 글로 적고 공유를 한다면
작성자 본인도 자신의 사고의 흐름이 어떻게 흘러가는지 알 수 있고
팀원들도 타 팀원들의 디버깅, 문제 해결의 사고를 익힐수 있지 않을까 기대해본다.