> 개요

오늘은 두번째 리팩토링을 진행하며 겪었던, 문제들과 내가 어떻게 해결해 나갔는지를 설명해보려고 한다.

현재 팀프로젝트의 모든 부분을 건드릴려고 하니, 내 부분도 다시 보니 잘 머리가 안들어오는데, 다른 팀원들거까지 보려고 조금 시간이 걸리는 감이 있지만, 그래도 끝까지 해보려고 한다.

내가 요번에 적용한 리팩토링은, 저번과 비슷하지만, 조금 다르다.

1. 컴포넌트화
2. footer를 상수데이터로 바꿔주었다

1️⃣ 컴포넌트화

첫 번째 리팩토링을 진행할 때와 동일하게 먼저, 컴포넌트화를 시작해주었다. 그렇게 해야, 코드가 너무 길어지지 않을 뿐더러, 가독성도 좋아지고, 기능, 특정한 파트에 따라 나뉘어져 있어서, 혹시나 데이터를 바꿀경우나 수저해야 할 부분이 있으면 쉽게 찾아볼 수 있는 효율성이 증가해서다.

사진과 같이, 80줄이였던, 메인 컴포넌트가 분리를 해두니 8줄로 10배가 줄었다.

리팩토링을 하면서, 매번 느끼는 거지만, 컴포넌트화를 진짜 제대로 해놓는게, 당장은 귀찮을지 언정, 추가, 수정을 할때, 효율성이 증가한다는 것을 많이 느낄수 있는 작업이었다.

2️⃣ 기본 Footer를 상수데이터로 변경

기존의 footer에 회사 정보며 전화번호 등등 정보가 엄첨 많았다. 그리고 이 데이터들을 따로 분리해두지 않고, 하나의 컴포넌트에 다 합쳐서 모아 놓다보니, 지저분해보일 정도로 많았다.

그래서, footer 데이터는 상수데이터로 따로 관리해 주기로 했다. 그 이유야, footer있는 UI구성에는 필요하지만, 동적으로 변하지 않아서 백엔드 api등을 통해 가져올 필요가 없는 데이터이기 때문이다. 상수 데이터는 변동이 많이 없는 것이 특징이다. 보통 회사의 이름, 회사번호 등등 이런 정보들을 알려주는데, 그런 것들은 바뀔 유동성이 많이 없는 정보다 보니, 상수데이터라고 부른다(정적인 데이터).

왜 상수데이터를 사용해야 하냐??
반복되는 UIfmf 하드코딩으로 일일이 만들어두게 되면 코드도 엄첨 길어지 가족성이 특히 좋지 않고, 수정이 필요할 시 해당하는 부분을 찾기가 힘들기 떄문이다.

위의 사진처럼 데이터들을 배열, 객체화 해주어, 활용할 수 있다.

map 메서드를 활용하여 동일한 UI를 반복할 것이다.

결과적으로, 바꾸어 주면서 효율적으로 수정도 가능한 코드로 변경을 해주었다. 하면서 key 값을 새롭게 넣는 방법도 발견했지 때문에, 기분좋게 학습할 수 있었다.