부스트캠프 멤버십 그룹프로젝트 3주차를 마쳤다.
세상에 벌써 3주차가 끝났단말이야?
배운것
이번 주는 코드적인 부분을 많이 학습할 수 있었다.
Context API는 상태관리 도구가 아니다.
모든 시작은 Modal에 대한 고민으로부터 시작했다.
요런 고민들을 했었는데, 이런 고민들을 멘토님께 공유드리니, 멘토님께서 이것 뿐만 아니라 모달이 여러개라면 어떻게 할 것이냐는 질문을 던져주셨고, @ebay/nice-modal-react라이브러리를 알려주시며 해당 구조를 한번 살펴보라고 해주셨다.
그래서 무작정 코드를 뜯어보기 시작했는데, 여기서 Context API를 사용해서 모달을 관리하는 것을 확인할 수 있었다.
그런데 상태라기보다는 값 관리를 위해 Modal 고유의 ID를 주입한다던지... 이런식으로 사용되고 있었다.
물론 나는 Context API를 상태관리의 관점에서만 바라봤기에 이걸 이해하는데 굉장히 많은 시간이 필요했다.
매번 상태관리 라이브러리와 비교하며 단점위주로 생각했었는데, 이런 방식을 보니 정말 새로운 세계가 열린 느낌이었다.
또한, 전 주에 Context API의 단점이 명확하다고 했었는데, 이부분도 상태끌어올리기 등을 통해서 충분히 극복해낼 수 있다는 것을 알게됐다.
https://solo5star.tistory.com/42
React Context를 쓰면 전체가 리렌더링된다고?
리뉴얼 된 블로그로 보기: https://solo5star.dev/posts/42/ const App = () => { const [mousePosition, setMousePosition] = useState([0, 0]); // 마우스 움직임을 감지하여 mousePosition 상태 계속 업데이트 useEffect(() => { document.ad
solo5star.tistory.com
현재는 이걸 적용시켜서 공통모달을 만들어보았다! (곧 정리해서 업로드 해볼 예정이다)
굉장히 좋은 방법을 하나 얻어가는 것 같아서 기쁘다.
개선해야할점
부족한 명세
이번주차의 우리팀 목표는 어찌됐던 모든 기능을 구현하는 것이었다. 그래서 더 더 빠르게 구현해내야했고, 그러다보니 에러 처리가 안된 부분이나 각종 엣지케이스가 있기도 하고, 여러가지 케이스들에 대해 고려하지 못하고 빠르게 구현하여 어느 기능이 어떻게 구현되어야할지가 조금 모호한 부분이 있었다.
이런 문제들을 월요일 회의 시간에 백로그 작성에 조금 더 시간을 쓰는 방식으로 개선할 수 있을 것 같다.
로그인 그냥 하면 되지? 보다는 사용자 입장에서 어떤 흐름으로 우리 서비스를 사용할지를 조금더 고민해보고 자세하게 백로그를 작성해보는 방식으로 논의를 거쳐 개발한다면 부족한 부분을 더 채워나갈 수 있을 것이다.
작업 시간 측정하기
정말 의식적으로 작업 시간이 얼마나 걸리는지 측정해보려고 했는데 정말 어려웠다.
보통 12시쯤부터 코드를 작성하기 시작하는데 이때부터 todo list를 작성해놓고, 일을 시작하긴 한다.
하지만 집중하다보면 다 잊고 정신차려보면 3~4시인 경우가 허다했다...
모든 개선의 시작은 측정이다. 측정이 되어야 문제를 확인하고 좀 더 개선해볼 수 있을텐데... 쉽지않다.
중간에 쉬는시간을 가져가면서 의식적으로, 아니면 타이머라도 써서 좀 더 측정해볼 필요가 있다.
뽀모도로 타이머를 써볼까 한다.
테스트코드
첫주, 둘째주에는 그래도 테스트코드를 얼추 작성해가면서 진행했으나, 3주차쯤되니 테스트코드가 없는 코드가 굉장히 많아졌다. 이러면 이후에 성능개선을 할때도 꽤나 힘들어 질것이 뻔하다.
기능구현을 마쳤다면 테스트코드도 꼭 작성하자.
