코드를 컴포넌트화 시켜서 유지, 보수에 용이하고, 가독성도 좋은 프로그램 만들기

1. 중복되는 코드를 컴포넌트 화 해버리는 이유

**컴포넌트 화 란?

중복되는 코드를 하나의 컴포넌트(함수)로 만드는 것을 의미한다. 

컴포넌트 화 시키는 이유는,

 

첫 번째 전체 코드의 코드양이 줄어든다. 

여러 줄 짜리 코드도 함수 하나를 호출하여 그 안에 인수를 집어넣는 방식으로 표현하면 코드 양이 훨씬 줄어 가독성이 좋아진다. 

해당 return 내부의 필요한 모든 코드들을 컴포넌트 호출을 통해 표현했다. 컴포넌트 호출 6번으로 return 문 내부를 필요한 것을 전부 표현했는데, 만약 코드로 위 사항을 전부 다 표현했다면, 스크롤바를 한참 내렸어야 할 것이다. 

 

두 번째, 유지보수가 용이하다. 

A란 코드가 5번 중복된다고 하자. 만약 2번째 4번째 A코드에서 버그가 발생하면 우리는 그 코드들을 찾아서 일일히 고쳐줘야 한다. 이는 아주 간단한 작업이라도 유지 보수에 상당한 시간이 든다. 

반명 A란 코드를 컴포넌트화 시키고, 필요한 5곳에 호출하여 썼다면, 나는 A 코드가 담긴 컴포넌트 하나만 수정하면 된다.

 

 

2. 하지만 너무 잦은 컴포넌트화는 예상치 못한 변경점이 생겨 버그로 이어진다. 

중복이 얼마 되지도 않은 코드들 까지 모두 컴포넌트화 시키면 어떤 일이 발생할까? 

예를 들어 버튼을 누를 때마다 횟수가 카운트 되는 코드를 컴포넌트화 시켰다고 가정해보자. 해당 코드는 A와 B 라는 장소 두 곳에서만 쓰인다.

근데 B라는 장소에는 버튼을 누른 횟수가 50번이 넘었을 때, 경고음과 경고문이 뜨는 코드도 추가해야 한다고 가정해보자.

만약 컴포넌트화 시키지 않았다면, B라는 장소에서 코드를 고치면 되었는데, 컴포넌트화 시켰음으로, 컴포넌트에 새로운 코드를 추가하고 보내줄 새로운 인수도 명세 해야한다. 

이러고 프로그램을 돌리면 A 장소에서는 Bug가 날 수 있다. 왜냐하면 property로 받아야할 인수가 늘었음에도 A라는 장소로부터 온 인수는 그대로 이기 때문이다. B를 고치는 바람에 A도 수정 작업이 필요하다...

만약 버튼 누를 시 횟수 카운트 컴포넌트를 C나 D라는 장소에서 쓰는데, 여기는 50번 넘겨도 경고문을 띄울 필요가 없을 경우, 원래는 그냥 버튼 카운트 코드만 작성하면 되는데, 경고음, 경고문 띄우지 말도록 하는 작업을 또 해줘야 한다! 

이는 번거로울 뿐만 아니라 버그 유발을 많이 한다. 

 

 

3. AtomicDesignPattern에 대해

AtomicDesignPattern은 프로그램을 만드는 방법 중 하나다. 

가장 작은 단위의 컴포넌트들을 미리 만들어두고, 상대적으로 큰 컴포넌트를 만들 시, 작은 컴포넌트들을 조합하여 만든다.

또 우리가 조합하여 만든 컴포넌트보다 큰 컴포넌트를 만든다면, 지금까지 만들었던 컴포넌트들을 조합하여 만들고,

이러한 과정을 반복하여 하나의 큰 프로그램을 만드는 방식을 AtomicDesignPattern이라고 한다. 

 

이때 만들어진 컴포넌트의 크기 별로 계층이 존재한다.

Atomic : 더 이상 쪼갤 수 없는 디자인의 최소 단위를 말한다. (예시 icon 하나 하나)

Molecules: Atomic들을 모아서 만들어지고, 최소 한 가지의 기능을 수행할 수 있는 단위를 말한다.

Organisms: Molecules랑 Atomic이 조합되어 만들어지고, 사용자에게 의미를 전달하거나 역할을 부여할 수 있는 단위를 말한다.

Template: Organism들이 조합되어  만들어지고, data가 연결되지 않은 최종 레이아웃을 의미한다. 

Page: Template에 data가 연결된 형태를 뜻하며, 사용자에게 최종적으로 전달되는 것이다.

 

https://yozm.wishket.com/magazine/detail/1531/

Atomic Design Pattern의 Best Practice 여정기 | 요즘IT

** 그렇다면 언제 얼마나 컴포넌트 화를 하는게 적절할까? 

이건 사람마다 기준이 다르지만, molecule 이상 단위의 코드가 3회 이상 반복될 시 컴포넌트화 시키는 것이 적절한 것 같다.

4. Dumb Component와 Smart Component에 대해  

Dumb Component란 사용자에게 무언가를 보여주는 일 외에는 아무런 기능을 하지 않는 컴포넌트를 말한다. 

만약 App의 어떤 헤더를 눌렀는데 아무 반응이 없다면, 해당 헤더는 지금이 어떤 페이지인지 말해주기만 하는 Dumb Component이다.

 

smart Component는 사용자의 동작에 따라 상태를 가지고 변하는 컴포넌트를 의미한다. 

아까의 예시에서 App의 헤더를 눌렀는데, 다른 페이지로 갈 수 있는 메뉴가 밑에 표시된다면, 해당 헤더는 지금 사용자가 어떤 페이지에 있는지를 나타내줄 뿐만 아니라, 사용자의 클릭에 따라 다른 상태를 가지는 Smart Component이다.