TIL - 팀 프로젝트에서 SOLID 원칙 적용 경험 공유

이번 TIL에서는 팀 프로젝트를 진행하며 SOLID 원칙을 적용해 본 경험을 공유합니다. 설문조사 모달 창에서 단일 책임 원칙과 인터페이스 분리 원칙을 중점적으로 적용하여 리팩토링을 진행했습니다. 이 과정을 통해 모듈화와 재사용성을 개선하고자 했습니다.

 

SurveyModal 리팩토링 하기전 필터링 하는 메서드

 

리팩토링 과정

1. useFilterFoods 커스텀 훅 분리
   • 목적: SurveyModal에서 렌더링과 관련된 로직만 남기고, 데이터 처리 로직을 useFilterFoods 커스텀 훅으로 분리
   • 구현 내용:
     • 점수 계산 및 데이터 필터링 로직을 useFilterFoods 훅으로 이동
     • SurveyModal은 설문조사 관련 UI와 로직만 처리
   • 결과: 모듈화와 재사용성 향상
2. 컴포넌트 분리
   • 목적: 컴포넌트를 더 분리하여 역할을 명확히 하고, 코드의 유지보수성과 재사용성 향상
   • 구현 내용:
     • FoodList와 FoodItem 컴포넌트를 분리
   • 결과: 각 컴포넌트가 하나의 특정 역할만 담당

적용 원칙 및 결과

useFilterFoods  커스텀 훅

1. 단일 책임 원칙 (Single Responsibility Principle, SRP)
   • 설명: 각 컴포넌트나 모듈이 하나의 책임만을 가지도록 하는 원칙
   • 적용 사례: useFilterFoods 커스텀 훅을 사용하여 데이터 필터링 기능을 분리
   • 이점:
     • 유지보수 용이성: 각 모듈이 하나의 책임만 가지므로 수정 및 유지보수가 용이
     • 재사용성: useFilterFoods 훅은 다른 컴포넌트에서도 쉽게 재사용 가능
     • 가독성: 각 모듈의 책임이 명확해져 코드 이해가 쉬움
2. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)
   • 설명: 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않도록 하는 원칙
   • 적용 사례: 컴포넌트의 역할을 분리하여 각 컴포넌트가 불필요한 메서드에 의존하지 않도록 함
   • 이점:
     • 명확한 역할 분담: FoodList는 음식 목록을 관리하고, FoodItem은 개별 음식 항목을 렌더링
     • 유연한 변경: FoodItem의 레이아웃이나 스타일을 변경해도 FoodList에 영향을 주지 않음
     • 재사용성: FoodItem 컴포넌트는 다른 곳에서도 독립적으로 사용 가능
3. •