HoneyMoney Refactoring (+Component 재사용)

배워야할 부분이 많지만, 진행했던 프로젝트에 대해 부족한 부분을 채우고 필요없는 부분을 다듬으면서 Code Refactoring을 해볼 예정이다.

 

1. Refactoring

2. Component의 분리 (현재 View 14개, Component 7개)

3. 무분별한 store 사용

4. 중복 코드 및 미사용 코드 정리

5. Profile 페이지에서 Detail 확인 시 스크롤 자동 하단 고정

6. Profile 페이지에서 꿀통에 담은 상품 제거 시 버그 발생

 

디버깅하면서 느낀 것인데, pinia의 persist를 제거하고 하는 것이 오류가 덜 나는 것 같더라. 물론 로딩은 걸리지만 ㅎㅎ

 

왜 Component를 진작 사용하지 않았는가?

 

기능 구현이 우선이다고 생각하고 신경쓰지 않았던 부분이다. 처음에는 오히려 편했다. 한 스크립트 내에서 구현하면 되니 파일을 찾아서 이동하고 붙이지 않아도 문제가 없었으니까. 하지만 2-300 줄의 코드가 쌓이다보니 사용된 함수 명이 섞이기 시작하고, 불필요한 중복 호출이 생기기도 했다. Vuetify로 이미 레이아웃과 위치를 짜놨다보니 귀찮아져버려서 이 상태로 프로젝트를 종료해버렸다. 

 

결국 css로도 중복되기 시작했고, 울며 겨자먹기식으로 보수공사만 진행해버렸다. 마치 건축으로 따지면 불법증축공사랄까..? 역시 건축에서도 모듈러가 유행인데, 코드도 그런 이유가 있었던 것이다. 또, 재사용도 점점 어려워지기 시작했다.

 

중간부터 굉장히 후회했던 부분인데, 상품 Detail 페이지를 확인할 때 dialog를 사용했다. 따로 페이지를 이동하여 Detail을 띄우는 것은 UX적으로 아쉽다고 생각했다. 또, 여러페이지에서 확인할 수 있다고 생각했기 때문에 '코드를 한번 짜놓으면 복사 붙여넣기를 하면 되겠지 ?' 라며 과소평가했다.. 결과는 처참했다.

 

Detail 페이지가 필요한 View는 4개였고, 가장 긴 코드를 갖고 있는 ProfileView는 770줄에 육박했다. 나중엔 GPT도 퉤 뱉더라.

 

심지어 페이지를 만들 때마다 store에서 함수를 새로 만들고, 변수를 할당했기 때문에 코드 길이도 기본 100줄이 넘어간다. 결국 우리가 필요한 건, 상품의 정보와 유저의 정보 뿐인데 말이다.

 

한번에 드라마틱하게 줄이기는 어려울 것 같고 하루에 한개씩 차근차근 줄여보자. (심지어 FIND BANK Tab에 불러오는 Detail 페이지는 담긴 정보조차 간소화 되어있다)

 

 

금융 상품 Detail Page의 Component화

 

가장 만만한 DepositProductsView.vue 부터 수술에 들어가자.

코드를 살펴보면, v-data-tablevirtual을 통해 표 테이블이 생성되고, 상품명에 button을 달았다.

해당 버튼을 누르게되면 showDetails 함수가 실행되는데, 이때 item의 상품명을 전달하게 된다.

 

왜 상품 code 가 아니라 상품명을 사용했을까? 가상 테이블 작성 시 강제로 데이터가 경우가 생겼기 때문이다. 

이런식으로 상품코드가 이쁘지도 않다.

 

즉, 상품코드를 통해 데이터를 넘겨주고 싶으면 UI를 포기해야 했기 때문에 번거롭지만 상품명을 통해 Detail 데이터를 채워나가는 방식을 사용했다. 이는 적금페이지에서 문제가 될 예정인데, 일단은 넘어가자.

 

이렇게 v-dialog를 통해 데이터를 pop-up 시켜주는 방법이었다.

 

하지만 컴포넌트를 사용하면 굉장히 간략하게 이동이 가능하다. 코드의 가독성도 높일 수 있었는데, 약 200줄의 코드가 DepositDetailComponent로 이동하게 되었다. (ProfilePage 때문에 SavingDetailComponent와 구분할 예정)

진작 이렇게 할걸..

이렇게 되므로써 deposit list 페이지 뿐 아니라 다른 페이지에서도 해당 컴포넌트를 불러올 수 있게 되었다. (물론 데이터를 잘 넘겨준다는 가정 하에)

 

어? 근데 Props 데이터를 넘겨주지 않고 있다. 왜요?

클릭 이벤트는 상품명을 통해 데이터를 찾고 'store'에 저장

 

이 부분에서는 취향이 나뉠 수 있을 것 같다. 

 

1. View 페이지(혹은 Component) 내부 Axios를 통해 데이터 변수를 따로 저장하여 바로 출력 및 Props로 전달하는 방법

2. Store 에서 데이터를 호출하여 Vue 파일 스크립트 내부를 깔끔하게 해두는 방법

나는 2번을 택했다. 그러라고 있는 Store아닌가?

 

즉, 굳이 데이터를 넘겨주지 않고 Store의 Detail(상세정보)를 Component로 끌고오는 것이다. 그리하여 335줄의 DepositProductsView는 각각 200줄과 130줄로 나뉘게 되었다. 추가로 필요없는 부분을 확인 했는데, Chat GPT를 난무하다보니 제대로 배우지도 않은 watchEffect가 있더라. 물론 사용에 문제가 되는 부분은 아니지만, 불필요한 부분으로 판단했고 watch는 정확히 명시하는 타입이기 때문에 최대한 watch를 사용하려고 했다.

 

depositView

depositStore

 

애초에 변수도 겹쳐서 사용되어 있었다. 따라서 나는 watchEffect를 삭제하고 Store에 정의되어있는 빈 배열에 초기 값으로 "모든은행"을 넣어주었다. 결과적으로 같은 기능을 한다. 

이렇게 모든 은행도 볼 수 있고, v-select의 힌트도 사용 가능하다

 

이제 컴포넌트 하나 나눴는데 갈길이 멀었다... 맨처음 언급한 4개의 다른 요소들을 한번에 해결한 것 같지만 각 페이지마다 전달하는 데이터가 달랐기 때문에 결국 View를 수정해줘야한다. 차근차근 해봐야징.