4주 프로젝트 회고

배포링크 : https://aneun-dongne.com/

깃헙 레포지토리 : https://github.com/codestates/aneun-dongne

팀 노션 : https://www.notion.so/10-tenten-aneun-dongne-674a1986f8f144a0a63d6cbaefb857ff

 

 

아는동네 프로젝트소개

아는동네는 사용자위치를 기반으로한 국내 관광지 소개 서비스이다.

좋아요, 댓글, 해시태그등으로 관광지에 자신의 흔적을 남길 수 있다.

로그인 여부와 상관없이 관광지를 추천받을 수 있지만 마이페이지, 좋아요, 댓글작성은 비로그인 상태에서 제한된다.

 

기존 관광지 추천 서비스들과 차별화한 기능

기존 관광지 추천 서비스와의 차이점은 관광지가 아니더라도 마음에 드는 장소가 있었다면 저장할 수 있게 한 것이다.

이는 내가 미얀마에 여행을 갔을때의 경험에서 비롯된 것인데, 미얀마의 바간이라는 곳에서 기가막힌 노을이 보이는 석탑을 찾았지만 저장할 방법이 없어 구글맵에 직장이라고 저장해놓은 적이 있다.

나의 구글맵

다른사람들도 이러한 경험이 있을것이라 생각해, 꼭 관광지가 아니더라도! 마음에 드는 장소는 사진과 함께 그 위치를 저장할 수 있는 기능을 구현했다.

맘에 드는 위치를 마이페이지에 저장할 수 있다!

 

---

내가 한 작업에서의 개선사항 및 회고

모든페이지의 기능 시연은 팀노션 혹은 배포링크에서 볼 수 있다.

홈 화면 

다음과 같이 지도를 클릭하였을때 클릭한 위치 반경 10km의 관광지들을 리스트업되도록 만들었다.

거슬리는 점은 지도가 심하게 깜빡거리는 것과 관광지사진에 로딩인디케이터를 넣지 않은것

-> useEffect안에서 지도의 본판과 마커를 분리하여 해결

그리고 만들고 보니.. 지도를 더 크게 만들어야했다.

아래 화면처럼 지도위주의 페이지로 리팩토링을 해야할 것 같다.

https://yeonjewon.tistory.com/78

 

관광지 세부정보 페이지

이 페이지 핵심기능은 댓글 좋아요 밖에 없다.

이 페이지에서 댓글 수정 기능을 구현하는데 3일이 걸렸다. 댓글 CRUD 작업을 처음 경험하기에 겪은 시행착오들이라고 생각한다.

 

3일을 빼앗은 버그는 댓글을 엔터키로 작성했을때 '\n'까지 작성되던 버그였다. 처음에는 useEffect의 의존성배열에 state값을 바꿔가며 sideEffect로부터 setState를 보호하면 될 것이라 생각했는데 완벽한 헛다리였다. 나중에서야 우연히 알게된 버그의 원인은 props로 전달받은 '\n'이었다. '\n'이 렌더링되는것을 인지하지 못했기 때문에 생겼던 버그였다. 조건문으로 text가 '\n'일때 null을 리턴하게 하여 해결했다.

 

아래 페이지는 당시 게시글이다.

https://wnsdufdl.tistory.com/246

댓글작성시 엔터로 작성하면 두번째 렌더링인 '\n'이 작성되는 버그 (+14,+138

 

 

마이페이지 - 내가 저장한 장소

맘에 드는 위치를 마이페이지에 저장할 수 있다!

여기서는 어떤 카드(배열내 요소들)를 클릭했을때 항상 배열내의 마지막 카드의 정보(마지막 인덱스)가 들어있는 모달창만 보이는 버그였다.

정보 수정

그 이유는 배열 내 모든 인덱스의 정보가 모달창에 각각 담기고, 마지막에 생성된 마지막 인덱스의 모달창이 다른 모달창들을 다 가리기 때문이었다. 그러니까 카드가 4개라면 어떤 카드를 클릭해도 arr[0],arr[1],arr[2],arr[3]의 정보를 담은 모달창이 모두 오픈되고 마지막에 오픈된 arr[3]의 정보를 담은 모달창만 화면에 보이는 것이다.

 

설명하자면 기니깐 당시 상황을 기록한 게시글을 남기겠다.

https://wnsdufdl.tistory.com/254

배열을 map하고 각 인덱스의 자료를 모달창에 렌더링시킬때, 무조건 가장 마지막 인덱스의 자료

 

 

정보 삭제

마이페이지 - 프로필 변경

당연히 유효성검사도 클라이언트에서 한번, 서버에서 한번 총 두번하도록 만들었다.

 

유효성검사를 꼼꼼하게 하더라도 간헐적으로 유저의 정보가 서버로부터 전송되지 않는 버그가 있었다.

이유는 토큰이 만료되었기 때문이었다. 해결책으로 AWS에서 세션 만료시 로그아웃을 유도하는 모달창을 벤치마킹했다.

상황을 재연하기 위해 개발자도구에서 쿠키를 삭제하고 마이페이지에 진입했다.

 

---

프로젝트 진행

SR 단계

2주프로젝트때는 태스크 분배를 명확히 하지 않아 깃 충돌이 많이 일어났다. 이번에는 난이도별로 태스크를 공평하게 분배하였다.

확실히 누가 어떤부분을 맡고 있는지 명확했기에 추후에 오류가 생겼을때, 그 오류를 담당자에게 바로바로 공유할 수 있었다.

2주 프로젝트때도 느끼고 이번에도 느낀점은 내 담당이 아닌 기능은 절대 건드리지 않고 '~~해주세요' 라고 요청해야한다는 것이다.

꼭 당장 해야 하는 작업인 경우에는 수정후 통보하는것이 아니라 담당자에게 설명을 한 후 보는 앞에서 수정하였다.

아무리 사소한 것이라도 내가 모르는 새에 내가 작성한 코드가 멋대로 바뀌어있다면 사람인지라 감정이 1이라도 상할 수 밖에 없는것같다.

'태스크분배'가 효율성을 위한 규칙이기도 하지만, 이런 감정소모를 미연에 방지하기 위한 규칙이기도 함을 느꼈다.

 

또한 2주 프로젝트때와 달리 4주 프로젝트에서는 매일 오전 11시에 코드리뷰를 진행하며 깃 충돌을 다 함께 수정하였다.

깃 충돌을 다 함께 수정하였기에 코드가 꼬이는 일이 없었다.

매일 오전 11시 코드리뷰, 나는 이것이 우리 SR의 가장 중요한 항목이었다고 생각한다.

 

사용 스택 선정

 

2주프로젝트때와 같은점은 이번에도 카카오맵을 사용했다. 카카오맵을 다룰줄 아는 사람이 나뿐이었기에, 지도가 들어간 부분은 모두 내가 전담하여 작성했다. 원래 마이페이지의 지도는 다른 팀원분이 만들기로 계획했지만 유동적으로 계획을 수정하다보니 그 마저도 내가 하게 되었다.

 

2주 프로젝트때와 다른점은 전역 상태 관리 라이브러리를 리덕스가 아닌 리코일을 사용했다는 것이다.

풀스택을 맡으신 팀장님과 다른 프론트 팀원 한분이 2주프로젝트때 리덕스를 사용하지 않은 상황이었다.

팀장님이 리코일을 사용하는게 어떻겠냐고 제안하셔셔 리코일에 대한 자료를 찾아보았는데 꽤 매력적이었다.

비동기 처리를 위한 러닝커브가 비교적 적고, 캐싱을 지원한다는 점에 끌려서 리코일을 사용하기로 했다.(자동으로 캐싱을 해주기 때문에 갱신해야할 상황에서는 추가작업이 필요할 수 있다는 사실을 나중에 알게 되었다.)

그리고 무엇보다 리덕스보다 사용법이 쉽기때문에 리덕스를 사용하지 않은 두분이 빠르게 리코일을 공부해서 전역 상태관리를 하실 수 있었다.

 

리코일을 이용한 비동기처리를 하겠다고 계획했지만, 막상 프로젝트를 시작하니 손이 익숙한 useEffect를 사용하고 있었다. 리코일을 이용한 비동기처리를 하루 이틀 미룬채로 useEffect로 처리하다보니 모든 비동기를 useEffect로만 처리하게 되었다. 이건 잘못되었다 싶어서 뒤늦게 '홈화면에서 지도의 좌표를 서버에 넘겨주고 관광지 배열을 받아오는 비동기 로직'을 리코일 selector로 작성하였다.

 

긍정적으로 생각하면 리코일 selector를 이용하여 비동기 처리를 하나라도 경험한것이 잘 된 일이지만 냉정히 생각하면 나머지 비동기를 useEffect를 이용하였기 때문에 리코일을 사용한 의미가 크게 없는것 같다.

 

그래서 리팩토링때는 리코일 selector를 이용한 비동기처리를 완성해보기로 했다.

---

반성

지도들어간 페이지 리팩토링

아까 서두에 말했듯, 지도가 있는 페이지는 지도 위주의 화면으로 리팩토링 해야 한다.

지도가 페이지의 메인 기능이기 때문이다.

 

 

아는동네 홈화면

내 롤모델 (출처 https://yeonjewon.tistory.com/78)

태스크카드를 분배했음에도 불구하고 처음에 서버를 건든것

최신댓글이 아래부터 쌓이는 구조(array.push)를 위에서부터 쌓이도록(array.unshift) 컨트롤러를 수정하고 후에 이야기를 했는데, 나중에 서버 담당자분이 이거 왜 바꾸신거냐고 물어보셨다. 2주 프로젝트때 겪었던 소통의 부재와 똑같은 상황이었다. 사소한 일이지만 잘못이라고 한다면 분명한 내 잘못이었다. 반성하고 그 이후에는 수정사항이 있을때마다 해당 담당자분과 zoom을 키고 수정할 부분을 먼저 설명을 한 후 해당 담당자분이 보는 앞에서 수정을 하였다. 딱 한번이지만 매너리즘에 빠져 소통을 하지 않았었다. 다음부터는 한번 실수를 하고 그 이후 개선사항을 보이는 것이 아니라, 애초부터 똑같은 실수를 반복하는 일이 없어야겠다.

 

 

위치기반 서비스를 만들면서 모바일 화면부터 만들지 않은것

위치기반 서비스를 만들고 있으면서 데스크탑 화면부터 만들었다.

후에 이틀을 남기고 부랴부랴 반응형 작업을 하느라고 많은 스트레스를 받았다.

좀더 SR을 꼼꼼히 했어야 한다.

경험부족으로 겪은 애로사항이라 이번 경험은 성장의 밑거름이 되었다고 여기겠다.

 

리코일을 전역 상태 관리 라이브러리로만 사용한것

리코일을 사용하기로 선택한 이유는 러닝커브가 적은 비동기처리(캐싱, redux-thunk보다 간편한 사용법)였다. 그럼에도 불구하고 결국 전역 상태를 관리하는 용도로만 사용했다.

나는 리덕스를 사용했던 상태라, redux 미들웨어의 역할을 하는 recoil selector의 존재를 인지하고 있었지만, 팀원들은 전역 상태 관리만 생각했던것 같다. 좋은게 좋은거라는 안일한 매너리즘에 일단 useEffect로 비동기처리를 작성했었는데, 만약 내가 recoil selector를 이용한 비동기 처리방법의 존재를 한번 언급하는 선에서 그치지 않고 여러번 이야기하고 공부하자고 제안 했으면 어땠을까 하는 생각이 뒤늦게 든다.

 

연말까지 리코일 비동기 공부를 알차게 하고 신년부터 다시 팀원들과 리팩토링을 신나게 하겠다.

 

Local Storage에 저장하는 것은 안좋다는 고정관념때문에 recoil persist를 사용하지 않은것

다른팀들보니까 redux-persist를 많이 사용했다. 내가 너무 고정관념에 빠져있었던것같다.

비밀번호 같은건 Local Storage에 저장하면 안되겠지만 글쎄.. 다른 데이터들은 괜찮을수도??

내가 너무 예민했던것같다.