4 Weeks Project Diary

#Sprint4 - Day 6.
Javascript를 배우고 있습니다.
현재는 길고양이들을 돌보는 모바일 앱을 제작하는 4주 프로젝트 중입니다.

1. Sprint4

1. 목표(100%) vs 달성(85%)

• 4번째 스프린트가 마무리 되었다. 3주차가 넘어가니 체력적으로 기운도 많이 빠져있고, 뒤쳐지는 스케줄 때문에 신경을 많이 쓰게 된다. 프로젝트 킥오프 때 계획했던 Srpint4 마무리에서는 기본 기능 100% 구현을 목표로 했었다. 스프린트를 마치고 보니 85% 정도 달성한 것 같다.
• 혹시 몰라 디버깅과 문서 정리를 위해 4일 간의 Sprint5를 남겨둔 것이 정말 다행이었다 싶다. 프로젝트에서 버퍼는 꼭 필요한 것 같다.
• 4번째 스프린트 리뷰 시작

2. To-do와 회고

1. to-do: 컴포넌트 구현

1. 포스트 댓글 구현

• 원래 이번 스프린트에서는 고양이와 관련되 뷰를 완료한 후 마이페이지 쪽으 만지기로 했는데 지난 스프린트에서 구현하지 못했던 고양이 포스트 별 댓글 기능을 구현했다.
• 지도 -> 고양이 스팟 -> 고양이 정보 -> 고양이 포스트(페이스북처럼) -> 고양이 댓글 구조로 되어 있어서 굉장히 깊이 위치한 nested component를 구현해야 했다.
• nested component라는 말은 이미 선제되어 있는 정보들이 mobX store에 많이 위치해 있다는 것이므로 유저 정보, 유저가 선택한 고양이 정보, 해당 고양이의 포스트 아이디, 기존 댓글들을 모두 참조하여 댓글 구성요소를 만들었다.
• 특히 댓글은 실시간으로 소통할 수 있는 공간이므로 '웹소켓'을 적용했는데 지난 프로젝트 때처럼 '댓글 추가' 시에만 웹소켓이 반응하여 실시간 렌더를 해줄 수 있도록 구현했다.
• crud를 고려하여 댓글 수정이나 삭제도 구현했는데 웹소켓으로 수정/삭제를 구현하는 경우에는 소켓이 전달하는 변경 값으로 인해 기존 댓글 순서가 헤칠 수도 있겠다는 논의에 걸쳐서 수정/삭제 시에는 클라이언트에서 기존 댓글을 store에서 지우고 새로 서버에서 정보를 받아오는 식으로 구현하였다.
• 프로젝트 일정으로 인해 이렇게 결정을 내렸지만, 프로젝트가 끝나고 나서 소켓 적용 시에 수정이나 삭제처럼 기존에 렌더된 사항에 대한 변경 사항은 어떻게 다루는지 좀 더 찾아봐야겠다.

2. 메인 화면 마커 별 고양이 정보 팝업창 구현

• 메인 화면 전반에 지도가 제공되는데 여기에 길고양이가 등록된 스팟마다 마커가 표시된다. 사용자는 이 마커를 클릭해서 간단한 고양이 정보를 확인하고, 해당 고양이 정보로 이동할 수 있게 기획을 짜둔 상태였다. 기획 내용대로 해당 고양이 정보를 간단히 보여줄 수 있는 'BriefCatInfo' 컴포넌트를 만들었다.
• 메인 화면이었기 때문에 애초에 구현해야 했지만 처음에는 주변 스팟들의 고양이들을 한꺼번에 볼 수 있도록 carousel이라는 모듈을 이용해 '옆으로 넘겨 보기'를 구현하려고 했다가 carousel을 옆으로 넘길 때마다 지도가 바뀌고 지도에 렌더되는 고양이 정보가 변경되어 고양이 정보가 계속 변경되는 이슈가 있어 계속 디버깅하다가 결국엔 팝업창으로 구현 형태를 변경하면서 구현 순서가 좀 미루어졌다.
• 구현된 고양이 마커별 팝업창

3. mobX store 리팩토링

• 스프린트 4가 되면서 백엔드 팀원 2명이서 일부 클라이언트 컴포넌트 구현을 지원하기 시작했다. 이 과정에서 기존에 구현했던 클라이언트 코드들을 수정, 참조하는 과정이 빈번해졌다.
• 최초 이 서비스를 기획하면서 처음 mobX의 개념에 대해 배우면서 redux와 달리 여러 개의 store를 구현할 수 있다는 점을 적용해보면서 2가지(고양이 관련, 사용자 관련) store를 구현했다. 그런데 시간이 지날 수록 핸들러 함수와 state격인 observable들이 늘어나면서 store의 가독성이 떨어지게 되었다. 2주간 클라이언트 코드를 부분 리뷰하던 동료들이 직접 코드 작성에 참여하게 되니 스토어 내 가독성이 떨어지는 것이 확연히 느껴졌다.
• 또 모바일 기기 내 위치 접근이나 카메라 접근에 대한 함수, 혹은 인풋 창을 채워넣고 비우는 등의 함수는 '고양이'나 '유저' 어느 스토어에도 딱 떨어진다고 볼 수 없는 것들이었다.
• 코드의 가독성과 정확도를 높이고 유사성을 가진 정보와 함수들을 모아두기 위해 코드 리팩토링을 결정했다. 이미 70% 이상의 함수를 구현해 둔 찰나였기에 리팩토링 결정이 쉽진 않았지만 mobX가 지닌 장점(여러 개의 스토어 보유 가능, oop 프로그래밍)을 더 살리고 다른 사람들이 볼 때에도 이해가 가는 맥락의 프로젝트 코드를 구성하는 것이 더 중요한 것 같아 이틀 정도 시간을 소요하여 리팩토링을 완료했다.
• 처음 '고양이' & '사용자'로 구분되었던 코드는 '인증', '유저', '고양이', '지도', '포스트', '댓글', '신고기능', 그리고 다른 함수들을 돕는 '헬퍼' 스토어로 총 8개로 나누게 되었다.
• 변경된 스토어 구조

4. 서버 연결 후 디버깅

• 각각 구현했던 컴포넌트들이 연결되고, 서버 셋팅도 완료되면서 드디어 로컬에서 서버를 가동시켜 서버와 클라이언트 코드의 합을 맞출 수 있었다.
• 예상했던 대로 restFul API에서 발견하는 에러들을 발견하게 되었고, 하나씩 디버깅을 구현하기 시작했다.
• 지난 프로젝트와 마찬가지로 값이 변경되었을 때 state 격인 observable의 값을 변경시키고 이에 따라서 가상 돔을 통해 변경된 구성요소만 새로 렌더시키는 방법이 가능하도록 디버깅에 신경을 썼다.
• 서버 연결 후 가장 많이 문제가 되었던 코드는 비동기 처리이지만 순차적으로 구현해야 하는 함수들이었다.
  예를 들어 회원 가입은 필드가 채워졌는지 검증 -> 서버에 가입 요청 -> 서버에서 사용자에게 이메일 발송 -> 클라이언트에서 response를 받아 사용자에게 alert를 주고 스크린 이동을 하는 플로우가 있는데 "서버에 가입 요청 ~ 클라이언트에서 response 받기" 전까지는 사용자에게 alert를 알리거나 페이지를 이동할 수 없기에 비동기처리가 끝날 때까지 동기적 코드를 홀드해야 하는 코드를 구현해야 했다.
• 길고양이 등록, 포스트 등록, 중성화 신고나 실종 신고 등이 모두 비동기적 처리를 하지만 비동기 처리가 끝난 시점을 판별하여 그 다음 함수를 실행시켜야 했고, 에러 코드에 따른 핸들링을 구현하는 부분에 시간을 많이 쏟았다.

2. 회고

1. 어려움을 느꼈던 부분들

• 사실 이번 스프린트에서 제일 어려웠던 건 mobX 리팩토링이었다. 처음에는 observable과 해당 observable의 값을 변경시킬 수 있는 handler 함수가 같은 store에 위치해야 한다고 생각을 했다.
• 예를 들어서 고양이에 대한 포스트를 남긴다고 했을 때, 고양이id, 포스트 내용, 함께 첨부한 사진 등이 사용자에 의해 화면에서 입력되고 선택된다. 그래서 처음에는 고양이 스토어에 '고양이 정보, 포스트 정보'를 함께 다뤄야 한다고 생각했다. 그런데 이런식으로 고양이에 물려 있는 정보가 굉장히 많다 보니 '도대체 고양이 스토어에 들어가지 않는 것은 무엇이 있을지'를 잘 모르겠다는 생각까지 이르렀다.
• 상태관리 라이브러리를 사용하지 않았더라면 여러개 컴포넌트에 흩어져 있을 함수들을 모아 단 2곳의 스토어에 관리하는 것이 쉽지만은 않았다.

2. 극복을 위한 노력들

• 다른 동료들이 코드 작성과 활용에 불편함을 느끼는데 구조를 개선하지 않는 것은 결국 나만 알아볼 수 있는 코드를 작성한다는 것에 가깝기에 정말 괴로웠지만 동료들과 논의를 통해 새로운 스토어들을 정의 내리고 리팩토링을 진행했다.
• 리팩토링 끝에 스토어별로 코드가 많이 짧아졌다. 함수 성격에 따라 일부는 활용하거나 변경시키는 observable이 다른 스토어에 위치하기도 했지만 스토어의 성격(고양이에 관한 것인지, 댓글에 대한 것인지, 신고 기능에 대한 것인지 등)에 맞춰 해당 observable을 불러올 수 있게 되었다.

3. 배움

• 리팩토링의 warnging이 뜨는 것은 정말 두려운 일이다. 프로젝트 진척이 잘 이루어져서 시간이 남아서 진행하는 리팩토링이 아닐 땐 더 그렇다. 그렇지만 모두가 협업하여 작성하는 프로젝트 코드의 경우에는 중간이더라도 리팩토링을 두려워하지 말고 기꺼이 진행해야겠다.
• 아, 무엇보다 이런 구조적 리팩토링의 문제를 기획 단계에서 먼저 더 깊이 고려해보는 것이 가장 큰 배움이기도 하다.

4. 다음 스프린트 계획

• 다음 스프린트 4일 간은 이번 스프린트에서 구현하려고 했던 마이페이지 쪽을 구현하고, 디자인을 보완한 뒤 앱으로 빌드하는 과정이 계획되어 있다.
• 갈 길이 멀다 힘내자.