레벨3 방학 동안, 팀 프로젝트의 리뷰 작성 페이지 리팩토링 작업에 몰입했다. 생각보다 많은 시간을 할애했고, 의미있는 작업이었다. 그래서 이를 기록으로 남기고 싶어 글을 적게 되었다.
리팩토링 이유
리뷰미 서비스 및 작성 페이지
🚀리뷰미 배포 사이트 바로가기
😆 리뷰미 version 1.0.0 소개 페이지
리뷰 작성 페이지
📼 구현 모습
- 서버에서 질문 데이터를 받아온다.
- 리뷰어(=리뷰를 쓰는 사람)이 첫 번째 카드에서 리뷰이(=리뷰 대상)의 강점들을 고른다.
- 2에서 선택한 강점 질문을 바탕으로 꼬리 질문들이 추가된다.
- 질문의 유형(선택/필수, 객관식/주관식)에 따른 답변 유효성 검사를 진행한다.
- 하나의 카드에 있는 모든 질문의 답변이 유효하면, 다음 버튼이 활성화된다. (답변이 유효하지 않으면 관련된 안내 문구를 띄운다)
- 리뷰어가 보는 리뷰 질문들,카드의 방문여부, 카드 속 질문들의 유효성 여부에 따라 상단의 프로그레스 바가 동적으로 달라진다.
- 모든 답변이 유효하면, 제출 전 확인 버튼(=답변 내용 확인)과 제출 버튼이 활성화된다.
- 제출 버튼을 누르면 수정 불가 여부를 안내하고 최종 제출할 수 있는 버튼이 있는 모달을 띄운다.
- 최종 제출 버튼을 클릭하면 서버에 답변을 보낸다.
- 서버에 답변을 보내는 요청이 성공하면 작성 완료 페이지로 이동한다.
- 만약, 리뷰어가 답변을 작성한 강점 카테고리에 대한 질문은 첫번째 카드에서 바꾼다면, 작성한 답변이 삭제된다는 모달을 띄운다. (확인시, 선택 해제가 반영된다.)
- 만약, 리뷰어가 리뷰 작성 중 Breadcrumb이나 로고 클릭 으로 작성 페이지를 나가면 리뷰가 삭제된다는 모달을 띄운다.
리팩토링 이유
🤓 리팩토링 이유: 유지 보수 측면에서 좋지 않은 구조
1. 복잡한 타입 및 상태 관리: 다양한 기능이 있고 이를 구현하기 위한 상태,훅들이 굉장히 복잡하게 얽혀 독립적이지 못하다.
2. 기능 확장이나 변경이 예상됨:서비스의 핵심 기능이며, 사용자 테스트를 미루어보아 질문지 변경이나 기능의 변경/삭제가 많은 페이지로 예상된다.
서로 밀접한 연관 관계가 있는 기능들
위의 기능만 보더라도, 현재 리뷰미 페이지 중 가장 많은 기능들이 들어있다.
문제는 이 기능들이 모두 리뷰어의 답변에 유기적으로 연관되어 있다는 것이다.
복잡한 데이터 타입
또한 질문과 답변 형식의 변화에 유연하게 대응하기 위해 여러 변수들을 생각하다보니, 서버에서 받는 질문 데이터의 형식과 서버에 보내는 답변 데이터의 타입이 복잡하고 서로 다르다.
🔍 리뷰 작성 페이지 데이터 타입 코드 보기
확장 가능성 있는 페이지
여기에 더해 리뷰 작성은 서비스의 핵심 기능이라는 점에서 앞으로 질문지 변경,답변 유형 변경 또는 추가등 다양한 기능 확장이 이루어질 수 있다. 그리고 실제로 사용자 테스트에서 가장 많이 피드백이 이루어진 부분이 리뷰 작성 페이지이다.
그래서 기능 확장 또는 유지 보수가 있을 레벨4 시작 전에 리팩토링이 이루어져야한다고 생각했다.
리팩토링 방법
리팩토링 기준 선정
🌟 하나의 기능에 대한 플로우가 잘 보이게 하자
혼자하는 프로젝트가 아니다보니, 다른 프론트엔드 크루가 리뷰 작성 페이지에 기능을 추가하거나 유지 보수에 들어가더라도 복잡한 상태 흐름을 쉽게 파악할 수 있는 것이 최우선 목표였다.
기존에는 리뷰 작성하는 훅에 프로그레스 바 상태를 변경하는 코드도 같이 들어 있었다. 이러면 프로그레스 바 상태를 변경할 경우 상태를 변경하는 곳을 일일이 찾아야하는 번거로웠다. 그리고 어디에 어떤 코드가 있는지 모르니 수정이 이러어져야하는 부분임에도 놓치고 가는 코드들이 있을 수 있는 상황이었다. 그래서 최대한 하나의 기능에 대한 작업을 할때, 그에대한 훅, 상태만 보면 될 수 있게 하고 싶었다.
리팩토링 방법
단일 책임의 원칙 지키기
하나의 기능에 대한 플로우에 집중하기 위해서는 우선적으로 생각한 것은 '단일 책임의 원칙'이었다.
모든 상태(질문지,프로그레스바, 답변과 답변 유효성, 케러셀 버튼등)을 완전히 독립적으로 분리할 수는 없지만, 최대한 책임을 분리해 하나의 기능만을 책임지도록 했다. 이를 통해서 하나의 기능에 대한 플로우가 잘 보이게끔 했다.
피그잼으로 도식화 하기
복잡하게 엮여있는 훅,상태를 분리할 때 피그잼을 활용해 상태, 기능의 흐름을 도식화했다.
흐름을 그리다보니, 복잡한 구조가 눈에 보였고 무엇을 바꿔야하는 지도 알게되었다.
무엇보다 좋은 점은 팀 내에서 리뷰 작성 페이지를 어떻게 관리하고 있는 지를 확인하는 하나의 기준이 생겼다는 거다. 프론트,백엔드 구분없이 리뷰 작성 페이지의 흐름이 궁금하거나 참고해야한다면 피그잼으로 쉽게 파악할 수 있다.
이는 레벨4 초반에 선택 질문의 유효성 조건을 변경할 때, 답변의 흐름을 파악하는데 도움이 되었다.
- 😆 피그잼이 흐름 파악에 도움이 되었다는 크루 코멘트
테스트 도입
테스트가 어려운 코드라면, 문제가 있는 코드다.
단일 책임의 원칙으로 역할을 나누면서 같이 그에 대한 테스트를 만들었다. 의도한대로 기능이 동작하는 지 확인하는 것이 가장 큰 의도였지만, 테스트를 짜는 과정에서 기능의 책임 범위를 다시 한번 확인하기 위함도 있었다.
테스트 케이스를 만들면서, 해당 훅이나 컴포넌트의 기능이 의도한 대로 하나의 기능으로 좁혀졌는지를 확인할 수 있었다.
그리고 테스트를 만들다가, 테스트가 까다롭다면 구조를 다시 확인했다. 테스트가 어렵다는 것은 해당 코드에 문제가 있을 가능성이 클 수 있기 때문이다.
테스트는 구현의도를 보여주는 또 다른 문서
테스트는 해당 코드를 짠 개발자의 의도를 다른 개발자들에게 보여주는 역할도 한다.
테스트는 케이스 문구 차체로 해당 훅, 컴포넌트의 역할이 무엇인지를 보여준다. 테스트 코드가 다른 개발자에게 구현 의도를 설명하는 또 다른 문서 역할을 하는 것이다.
🗂️ 추가된 테스트 목록들 보기- 강점 선택 여부에 따라 질문지 (cardSectionList) 변경 테스트
- 객관식 질문
- 질문 유형(필수/선택)과 답변에 따른 유효성 검사
- 최대 개수를 넘어서는 선택 시, 선택 막기 및 안내 문구 띄우기
- 주관식 질문
- 질문 유형(필수/선택)과 답변에 따른 유효성 검사
- change,blur에 따른 오류 메세지
- 현재 카드의 답변 상태에 따른 캐러셀의 다음 버튼 활성화 여부
- 현재 카드의 index에 따른 캐러셀에서 보여지는 버튼
- 질문지, 답변 유효성, 카드 오픈 여부에 따른 프로그레스 바 변경 테스트
기능별 폴더 구조 분리
기존의 컨벤션은 페이지 폴더 및에 components, hooks 폴더를 두는 것이었다. 그러나 리뷰 작성 페이지에 들어가는 컴포넌트와 훅이 워낙 많다보니 기존의 방식으로는 가독성(=기능의 플로우 파악)과 유지 보수 측면에서 한계가 있었다. 그래서 프론트엔드 팀원에게 현 상황을 공유한 후 관련 기능끼리 훅과 컴포넌트를 묶는 방향으로 폴더 구조를 정리했다.
마무리
👤 방학때 리팩토링을 하다니, 쉴 쉬간은 있었어?
🐋 아니... 바빴지만 후회없어. 값진 시간이었어
원래는 레벨3 방학때 이력서와 포폴을 만들려고 했다. 그러나 리뷰 작성 페이지 리팩토링 작업이 예상보다 엄청난 공사가 되어버렸다.
계획했던 공부나 이력서 준비등을 하지 못했지만, 그 보다 얻어간 것이 큰 시간이었다. 무언가에 이렇게 몰입할 수 있는 경험과 그를 통해서 내가 무엇에 진심이고 잘하는 지 알게되었다. 내가 어떤 개발자를 어필하는 좋은 경험을 해서 오히려 더 좋다!😆
열심히 만든 피그잼 도식화에 대해서도 리뷰미 팀원들과 코치 준에게 좋은 반응을 받아서 뿌듯하다.
(리팩토링 쉽지 않았지만, 끝내니까 달콤하고요~ 하늘 땅 만큼 뿌듯해)
