[TIL] 광고지구 프로젝트 리팩토링 대상 정하기 (1차)

 

기존에 v1 배포 후 원티드 인턴십을 하던 나는 연락을 한통 받았다 

"수인님! 저희 프로젝트 리팩토링 진행하는 건 어떨까요?"

초기에 프로젝트를 진행할때 구현하기에 급급했던 나는 사실 아쉬운 부분이 많았고 내가 담당했던 부분은 책임감 있게 완성하고 싶은 마음이 컸다. 

 

그렇게 시작된 v2 광고지구 탄생 

 

회의를 잠깐 진행하며 기존의 프론트 4명의 멤버에서 -> 3명으로 인원이 축소되며 구현했던 코드들을 확인해 보니 생각보다 파일관리가 너무 복잡했고 유지보수성이 불편하다는 판단이 나왔다. 

배포된 레포를 건들기에는 자동화 처리로 인해 혹시 모를 상황을 방지하고자 새로운 레포를 만들어 a-z 까지 새롭게 다시 진행하기로 했다. 

 

고민한 내용  

내가 적절한 컴포넌트 분리를  했는가 

팀원들과 코드 컨벤션을 잘 맞추며 작업을 했는가 

클라이언트 페이지가 너무 클론에만 급급했던 건 아닌가

 

어드민 페이지는 팀원들과 디자인부터 시작해서 오로지 프로젝트에 필요한 내용만 담겨있다면 클라이언트 페이지는 지구샵사이트를  클론 하다 보니 사실 프로젝트에 필요하지 않은 view까지 가져오는 경우가 있었고 해당 내용들은 팀원들과 회의하며 과감하게 불필요한 부분은 지우며 코드를 조금 더 깔끔하게 가져가기로 했다.

 

구현 완료 , 리팩토링 의 시작   

 

오늘 회의를 통해 고민한 내용과 변경해야 할 사항 

 

무엇을 리팩토링 해야 할까?

0. 중복된 코드 빼내기

 다른 두 메소드메서드 안에서 같은 코드가 있을 때 -> 하나의 메서드로  관리하기 

1. 쿼리 데이터 관심사 분리 

각  컴포넌트에서 보내는 개별 쿼리 요청들의 관심사를 묶어 하나의 파일에서 관리

 

2. 각 페이지에서 유저 정보 리다이렉트 처리  -> 유저에 따라 접근할 수 있는 라우팅 제한하는 Route 컴포넌트 처리 

하나의 Router 컴포넌트에서 유저 정보를 조회하며 해당 유저에따른 리다이렉트 처리

 

3. 사용하지 않는 method or package import ,불필요한 로그, 주석제거

4. alert -> toastUI 통일화 

alert ( error)  ⇒ toast.error(’’)

alert ( success )   ⇒ toast.success(’’)

 

5. api 관심사 분리 

한 파일에서 관리되는 모든 api -> 해당 관심사별 분리 

 

6. 각 페이지 Lighthouse 성능 개선 

각 담당 기능 개별 Lighthouse 측정 후 추가 개선사항 자료 조사 및  성능 개선 

 

 

 

이 외에도 리팩토링 할 내용들은 무수히 많지만 대략적인 큰 부분들만 먼저 작업하며 차근히 진행해 나갈 예정이다! 

 

 

요즘 나의 상태

프로젝트의 끝은 어딜까... 아마 없겠지...? 🥹