🤔 들어가며
개발을 시작할 때 바로 코드를 작성하던 나에게 컴포넌트 단위로 개발하는 방법을 배운 후로 항상 고민에 빠졌다.
팀원들과 비교해보면 모두 컴포넌트 분리 방법과, 내부 로직의 위치 등이 다 다르다는 것이다. 그러다 나는 어떤 방법이 더 좋은 방법일까? 항상 고민했지만 뭐가 좋은 방법인지 기준이 없어서 선택하지 못했다.
그러다 데브코스 강사님께서 컴포넌트를 잘 설계하는 방법의 예시를 보여주시기도 했지만 아직까지 내가 만족하지 못하는 이해였다.
이러한 고민을 멘토님께 각 컴포넌트들의 역할과 잘 설계하는 방법에 대해 물어봤고 멘토님께서는 각 컴포넌트는 하나의 기능을 가지고 하나의 기능에 관련된 로직은 내부에서 처리하는 것이 좋다라고 하셨다.
나는 컴포넌트를 잘 설계하면 정말 프로젝트가 깔끔해진다고 느꼈고 웹 개발에 있어 컴포넌트를 잘 설계하는 능력이 많은 비중을 차지한다고 생각하기에 공부를 더 해봐야겠다고 생각했다.
✅ 컴포넌트란?
컴포넌트
컴포넌트는 어떠한 시스템을 구성하는 요소 중 하나의 단위, 즉 소프트웨어 개발에서 재사용이 가능한 독립적인 모듈을 의미한다.
하나의 컴포넌트는 독립적인 모듈이므로 하나의 파일이 하나의 컴포넌트 역할을 한다.
🤔 컴포넌트를 분리하는 이유
컴포넌트들 왜 분리할까?? 어떤 장점이 있을까??
- 재사용성
재사용 가능한 컴포넌트를 만들면 동일한 기능을 수행하는 코드를 반복해서 작성할 필요가 없다. 이는 코드 중복을 줄이고 개발 시간을 절약할 수 있다.
- 유지보수
각 컴포넌트는 독립적으로 작동하므로, 한 커모넌트의 변경이 다른 컴포넌트에 영향을 미치는 것을 최소화 할 수 있다. 이는 유지보수를 간편하게 만든다.
- 가독성
작고 분리된 컴포넌트는 이해하기 쉽다. 각 컴포넌트는 명확한 역할과 책임을 가지므로, 코드의 전박적인 흐름을 파악하는 데 많은 도움이 된다.
컴포넌트를 분리하지 않으면?
컴포넌트를 분리하지 않고 하나의 파일에 모든 기능을 담는다고 생각해보자
코드 줄이 몇 천, 몇 만 줄이 넘어가고 오류나 수정이 필요한 부분을 찾는 것도 규모가 커지면 거의 불가능에 가깝다. 그리고 남들이 볼 때 이해를 하는 것도 불가능 하다.
추상화
컴포넌트를 분리했다고 장점이 자동으로 따라오는 것이 아니다. 컴포넌트 추상화를 잘했을 때 장점이 극대화 된다.
무작정 코드를 작성하기 전에 만들고자 하는 대상을 어떻게 컴포넌트로 잘 나눌 수 있을지?에 고민을 하는 것이 매우 중요하다.
👍 컴포넌트를 효과적으로 분리하는 방법
분리하는 이유를 살펴봤듯이 컴포넌트를 효과적으로 분리하는 것이 매우 중요한 작업이다.
컴포넌트를 효과적으로 분리하는 방법의 몇 가지를 살펴보면
- 단일 책임의 원칙(Single responsibility Principle)
각 컴포넌트는 하나의 기능만을 수행해야한다. 만약 컴포넌트가 너무 많은 일을 하거나, 여러 가지 역할을 수행한다면 그것은 여러 개의 컴포넌트로 분리될 수 있다.
하나의 기능을 수행하는 부분을 컴포넌트로 분리해보자
- 재사용 가능한 컴포넌트 식별
애플리케이션 내 반복해서 사용되는 UI 요소나 기능들을 식별하고 이들을 재사용 가능한 컴포넌트로 분리할 수 있다.
- 컴포넌트의 크기와 복잡성 확인
컴포넌트가 너무 크거나 복잡해지면, 이는 여러 개의 작은 컴포넌트로 분리할 필요가 있다는 뜻이다. 작은 컴포넌트는 이해하기 쉽고, 테스트도 하기 쉽다.
- 구조적 접근
컴포넌트를 페이지 > 섹션 > 모듈 > 요소 처럼 구조적으로 접근하게 되면 큰 틀로 분리하기 쉽다.
- 상태 관리 및 역할
상태를 다루는 로직이 복잡해지며 이를 관리 할 역할이 필요하다면 별도의 상태 관리 컴포넌트를 만드는 것도 좋은 방법이다.
- 주의할 점
이러한 방법들은 컴포넌들을 효율적으로 분리하는 방법이긴 하지만 모든 상황에 적합한 것은 아니다. 항상 어떤 상황에서 어떻게 추상화하냐에 바뀌는 것이다. 이를 활용하여 적절하게 선택하는 것이 중요하다.
😎 컴포넌트의 역할
컴포넌트에 대해서도 알았고 분리하는 방법도 알았다. 그럼 그렇게 짜여진 컴포넌트들은 각각 어떤 역할을 하고 있는지 알고 있어야 한다.
어떤 역할을 하고 있는지를 알아야 분리된 컴포넌트를 잘 활용하여 내부 로직을 깔끔하게 작성할 수 있다.
- 데이터 렌더링
컴포넌트는 상위 컴포넌트로 부터 전달받은 데이터(props)를 사용하여 UI를 렌더링한다.
전달받지 않고 컴포넌트 내부에서 데이터를 정의하고 사용하면 이는 재사용성을 하나도 고려하지 않는 방법이다.
컴포넌트의 역할은 전달받은 데이터를 기준으로 화면에 그리는 것이 제일 핵심 역할이다.
- 상태 관리
컴포넌트는 자체적으로 상태를 가질 수 있다.
상태를 가질 경우 사용자의 이벤트나, 상황에 따라 변경될 수 있으며 상태가 변경되면 컴포넌트는 다시 새로운 상태에 따라 리렌더링을 통해 새로운 UI를 그려야 한다.
- 본인의 기능은 내부에
컴포넌트가 가진 기능에 대한 이벤트 처리, 생명주기 관리 등 다양한 로직이 필요할 것이다.
본인의 기능은 자신 내부에서 처리하는 것이 가장 좋다. 다른 컴포넌트에 의존하지 않으며 독립성이 좋아진다.
만약 다른 컴포넌트에 대한 참조가 필요하다면?? 이는 상위 컴포넌트가 콜백함수를 props로 전달해줄 수 있다.
그렇게 되면 컴포넌트는 내부에서 자기가 할 수 있는 로직들을 다 처리하고 상황에 따라 다른 컴포넌트에 접근하는 로직은 콜백함수로 받아 그냥 호출만 시키면 된다. 이는 자기 자신의 로직에만 관심을 갖고 콜백 함수가 어떤 기능인지는 관심이 없다. 그냥 호출만 시켜주는 것 뿐이다.
🫡 잘 설계된 컴포넌트는 뭘까?
컴포넌트의 정의, 효과적으로 분리하는 방법, 역할을 통해 컴포넌트를 만들어도 상황에 따라 더 좋은 방법이 있다면 변경이 필요할 것이다.
그럼 더 좋은 방법의 기준이 뭘까?? 사실 제일 궁금했던 부분이다.
- 독립성
컴포넌트는 가능한 독립적이어야 한다.
독립적이다..? 이는 다른 컴포넌트에 의존하지 않고, 자신의 기능을 수행할 수 있도록 설계되어야 함을 의미한다.
독립성이 높아지면 재사용성과 유지보수 효과도 높아진다.
- 응집도
컴포넌트의 응집도는 높아야 한다.
응집도는 컴포넌트 내의 기능들이 서로 얼마나 밀접하게 관련되어 있는지를 나타내며 응집도가 높으면 독립성도 높아진다.
이는 컴포넌트 내의 메서드들이 단 하나의 기능만을 수행하고 이러한 메서드들이 내부에서 서로 밀집되어 더 단단한 컴포넌트가 만들어 진다.
- 결합도
컴포넌트의 결합도는 낮아야 한다.
결합도는 컴포넌트 간의 얼마나 의존성을 나타내며 결합도가 낮아야 독립성도 높아진다.
외부 컴포넌트의 참조를 최소한으로 줄여 필요시에는 콜백 함수를 통해 전달받아 결합도를 최대한 낮춰야 재사용성이 좋은 컴포넌트가 만들어진다.
😤 핵심은 독립성
잘 짜여진 컴포넌트를 판단할 때 독립성이 가장 중요하고 어떻게 보면 핵심 기준이다.
이러한 독립성을 높이기 위해 응집도와 결합도를 이야기하며 응집도는 높고 결합도가 낮아야 더 좋은 컴포넌트 모습을 보이게 된다.
😊 마치며
컴포넌트 개념과, 설계 방법, 역할, 좋은 컴포넌트의 기준에 대해 어느정도 공부해 봤는데 조금은 답답했던 고민들이 내려갔다.
데브코스 이전의 나는 개발을 할 때 바로 키보드 부터 두드리곤 했고 기능은 동작하지만 수정이 필요하거나 남들에게 보여줘야 할 때 정말 막막하고 부끄러웠다.
데브코스를 통해 컴포넌트로 분리하여 개발하는 방법을 배우고 아마 내가 제일 관심있던 분야라고 말할 수 있다.
항상 어떻게 하면 더 좋은 컴포넌트를 만들 수 있을까?? 이 로직과 핸들러는 이 컴포넌트에 위치하는게 좋을까?? 아니면 상위에 위치하는 게 좋을까?? 고민을 하곤 했던 것 같다.
어쩌다 정말 잘 짜여진 컴포넌트를 보고 정말 편하게 코드를 이해하고 재사용하고 수정도 정말 쉽고 특히 내가 원하는 부분을 찾기 쉬운 점이 너무 좋았다.
하지만 멘토님께서 말씀하시길... 컴포넌트를 분리하고 작성할 때 정답은 없다. 항상 상황에 따라 장 단점이 존재하고 우리는 상황에 맞는 가장 최선의 방법을 선택하는 것이다.
FE 개발자가 되기 위해선 컴포넌트를 잘 설계하고 작성하는 것이 정말 중요한 능력이라고 생각되며 더 관련된 자료들을 찾아 공부해봐야겠다.
