협업
혼자 할때는 타협점이 매우 낮았다. 어차피 과제니까, 재미로 하는거니까, 단순한 프로젝트니까.
에러처리는 그냥 console.warn으로 던지기 일쑤였고 new Error로 던지는건 양반이었다.
재사용 가능한 컴포넌트를 생각하지만 도중에 잡스러운 마음이 들기 쉽상이고...무의식적 코딩의 반복.
종국에 쓰레기같은 코드를 치고 있는 나 자신을 발견할 수 있었다.
그러다 이번에 협업을 처음 하게됐다. 긴장반 흥분반. 제대로 해본다는게 처음이어서 설레고 두려웠다.
예상했던대로 시작부터 힘들었다. 협업을 위한 규칙은 생각보다 정할 게 많았고 처음 해보는 작업 투성이었다.
특히 모르는 기술에 대한 규칙을 정할때가 제일 끔찍했다. 밑천이 다 드러나는 느낌이었다. 난 잘 모르는데, 어떻게든 말해야했다.
그래서 필사적으로 매달렸다. 공식문서를 계속 뒤져보고 잘 보지 않던 velog도 보게됐다. velog를 보다가 느낀점은 공식문서나 공식 개발자분의 링크를 걸어두고 번역하는 분들도 계셨단거다. 생각했던 것보다 퀄리티가 높은 글들이 정말 많았다.
아무튼...
당연히 쉬기도 했지만, 혼자 공부할때보다 훨씬 더 밀도가 높았다. 덕분에 이전보다 더 나은 사람이 됐다는 착각이 든다..ㅎㅎ
그리고 배려심 많은 팀원분들에게 항상 감사함을 느낀다. 다른사람의 의견을 바로바로 들을 수 있다는 것도 너무 좋다. 이 글을 보는 사람 중에 협업 경험이 없는 사람이 있따면 꼭 가져봤으면 좋겠다...!
chakra-ui
우리는 초기 기획단계부터 chakra-ui를 사용하기로 했다. 정확히는 한 팀원분께서 제시해주셨는데, 나도 동의했다.
최근 강의가 전부 Input, Form, Tab같은 재사용 가능한 기초적인 ui컴포넌트를 만드는 강좌였다. 이후 강좌에서 기초적인 ui컴포넌트들을 조립하여 작업하는데, 정말 좋은 경험이었다. 그래서 그런지 chakra-ui문서를 봤을때 비슷한 기술이라 생각이 들어서 강하게 밀어붙였다. 초기 러닝커브만 견뎌내면 코드 쓰는 시간을 획기적으로 줄일 수 있기 때문이다.(유연성이나 자유도는 다루지 않겠다)
결국 도입했고 잘 사용하고있다.
git
로컬 저장소와 원격 저장소. 커밋과 스태이징. rebase와 merge의 차이, 그냥 merge와 rebase and merge의 차이 등.
이론 상 알고 있었던 것도 있지만, 모르는 게많았다. 덕분에 큰일날뻔 한 적이 한두번이 아니다.
몸을 부딪혀가며 배우는게 제일 크다. 이제 충돌나거나 내 코드가 사라져도 당황하지 않을 자신이 있다.(정말?)
특히 git reset --merge와 git reset --hard ORIG_HEAD을 잘 써먹었다...😮
react-query
아직 ui만 작업해서 제대로 써보진 못했다. 다만 컴포넌트단에서 dispatch등 없이 바로 처리할 수 있는점과 에러처리, 캐싱 등 좋은 기능을 제공해주는 걸보니까 굉장히 사용할때 좋아보였다. 또한 onSucess, onError, onSetteld등으로 성공,에러,finally등을 처리해줄 수 있는데... 다음 메이저 버전에서 삭제될 가능성이 크다고 한다
다른 방법으로도 충분히 에러처리가 가능하니...잘 알아보고 해보자!
에러처리
목차를 따로 파지 않을까도 싶었는데, 생각을 정리해두기 좋을 것 같아서 적어둔다.
내가 생각해본 에러처리의 종류는 크게 두가지다.
- 클라이언트측 오류
- 서버측 오류
첫번째 핵심은 종류를 나누는 것이다. 서버측 오류를 예로 들자면 http status처럼 종류를 나눠놓으면 개발자가 처리하기 쉬울 것이다.
클라이언트측 오류도 이렇게 종류를 세분화하면...
ex)loginInput을 기준으로 들자면 email이 비어있다던가, password가 비어있다던가 이런 것도 다 에러처리를 하되 종류를 나눠놓는 것이다.
두번째 핵심은 에러처리를 어디서 할 것인가다. 에러는 필연적으로 발생한다. 나는 이렇게 생각해봤다.
- 먼저 전역적으로 처리하기
- 전역적으로 처리할 수 있다면, 지역적으로도 처리해보기
=>이때 Errorboundary를 사용할 수 있을 것이다. 좋은 글이어서 링크를 걸어두었다...
대신 지역적으로 에러처리를 한다는 게 크게 와닿지 않는다. 다만 크게 처리해두고 작은 규모의 에러를 잡아낸다는 건 이해했다.
하다보면 또 늘겠지? 대신 의식적으로 생각하는 게 중요하다.
storybook
쉽게 사용할 수 있을줄 알았으나 꽤나 애를 먹였던 기술이다. 애라고 해봤자 애드온 이거저거 설치해서 설정 삽입하는 게 전부긴하다.
"@chakra-ui/storybook-addon": chakra-ui의 theme이 먹히지 않을때 가져온 애드온. chakra-ui가 기본적으로 제공해주던reset css도 안먹혀서 가져왔더니 잘 됐다. 덕분에 contextApi와 Provider의 개념을 조금 더 이해할 수 있게됨.TS: 타입스크립트로 처음 하는거라 살짝 헤맸는데, 공식문서에 잘 나와있어서 고마웠다..storybook-addon-react-router-v6: react-router-dom과 storybook을 같이 사용할때 필요하다. 그냥 BrowseRouter등으로 컴포넌트를 감싸면 되긴 하지만, params등을 인식하지 못하는 문제가 있다.
느낀점
협업은 정말 좋다. 팀원분들이 워낙 좋으셔서 그런지 몰라도 아주 좋다. 특히 팀원분들에게 누가 되지 않기위해 열심히 공부하게 되는게 제일 크다. 또 코드리뷰를 거의 바로바로 받을 수 있는 것도 좋고 제 3자의 시선으로 내 코드를 볼 수 있는게 너무 좋다. 나와는 다른의견을 내주시는 것도 너무 좋다. 혼자 생각하면 매몰되기 쉽상이니까!
그런데 쓰다보니 최근 코딩테스트 공부를 아예 안했다는걸 깨달았다...!😯
프로젝트도 중요하지만, 기본기도 중요하다. 코테 1문제 풀 시간은 있으니 오늘부터 꼭 한문제...못할 거 같으니 강제성을 띄는게 좋겠다.😥
