FEConf KOREA 2021 에서 받은 인사이트

컴포넌트 다시 생각하기

영상바로가기

케이크를 만들때는 밀가루, 설탕, 계란이 필요하다.

케이크는 밀가루, 설탕, 계란에 의존한다.

케이크는 밀가루, 설탕, 계란에 의존성을 갖는다.

 

리액트로 생각해봤을때

리액트는 무엇에 의존성을 갖나?

반대로 생각해보면 리액트컴포넌트를 만들려면 무엇이 필요한가?

props hooks 로 데이터를 받아옴

특징적 분류 : 스타일, 로직, 전역상태, 리모트 데이터 스키마

 

케이크를 딸기케이크를 만들려면 딸기가 필요하다 그러나 딸기를 추가하려면 생크림이 더 필요하게된다.

이때 이 생크림은 딸기케이크를 만들기위해 딸기를 추가하는데 있어서 숨은 의존성을 갖는다고 볼 수 있다.

 

리액트컴포넌트또한 어떤 값을 하나 추가하려고 할때 해당 컴포넌트만 수정하는것이 아닌 상황에 따라서는 대상 컴포넌트와 루트컴포넌트 사이에 있는 모든 컴포넌트들의 수정이 필요할 수 있다.

 

비슷한 관심사라면 가까운곳에 (함께 두기)

스타일과 로직은 컴포넌트내에서 함께 두기 좋을것같다.

 

데이터를 ID 기반으로 정리

데이터 정규화 normalizr

 

GOI (Global Object Identification) Global ID 기반으로 특정객체를 가져오는 API

루트컴포넌트에서 가져온 데이터를 정규화하여 데이터 저장소에 저장

자식 컴포넌트는 아이디만 받아와 데이터 저장소에 요청 만약 원하는 필드가 없다면 API 서버로 데이터 요청하여 전달받아옴

새로고침시에도 유용함

 

이름짓기 - 의존한다면 그대로 드러내기

 

컴포넌트의 재사용 - 변경할때 유지보수할때 편리하기 위함

모델 기준으로 컴포넌트를 분리한다.

함께 변해야 하는것과 따로 변해야 하는것들에 대한 구분과 분리가 필요하다.

같은 모델을 의존하는 컴포넌트라면 재사용

다른 모델에 의존하는 컴포넌트라면 분리

 

정리

비슷한 관심사라면 가까운 곳에

데이터를 ID 기반으로 정리하기

의존한다면 그대로 드러내기

모델 기준으로 컴포넌트 분리하기

 

!! 질문이 정답보다 중요하다

!! 관점이 기술보다 중요하다.

 

GraphQL

 

현재 재직중인 회사에서도 발표내용에 나와있던 내용중 컴포넌트의 재사용과 유사한 케이스가 존재하기때문에 매우 집중도있게보았다.

재사용과 유지보수 그리고 어디까지 동일한 UI 로보고 동일한 컴포넌트를 사용할지 아니면 분리해야할지 항상 고민이고 실제로 개선이 필요한 컴포넌트가 당장에 떠오르기도 했다. 

 

 

우리는 응집도에 대하여 이야기할 필요가 있다.

영상바로가기

응집도란?

모듈이 책임질 역할을 위해서 필요한 데이터와 메소드들이 얼마나 서로 밀접하게 연관되어 있는지

 

세부적 분류

기능 / 순차 / 통신 / 시간 / 절차 / 논리 / 우연

 

기능적 응집도

모듈은 하나의 기능만 갖고 이 기능을 위해 모듈내의 모든 요소들이 존재하는것 그리고 이 기능을위해 이 요소들이 필수적으로 필요할때 기능적 응집도가 높다고 할 수 있다.

 

순차적 응집도

루틴이 특정한 순서대로 수행되어야하고 단계마다 정보를 공유하며 동시에 수행될때

퇴직금계산 메소드에 퇴직일 계산이 포함될때 퇴직일이 계산된 후에 퇴직금이 계산되기때문에 순차적 응집도를 갖는데 이를 기능적 응집도로 분리하면 즉 하나의 기능만 갖도록 분리한다면

퇴직일 계산 메소드와 

퇴직금 계산 메소드가 각각 분리되어 처리할 수 있습니다. 

 

통신적 응집도

모듈이 달라 서로 아무런 관계는 없지만 같은 데이터를 사용할때 통신적 응집도라고 얘기합니다.

 

시간적 응집도

 

 

논리적 응집도 (중요)

여러가지 기능을 하나의 루틴에서 수행할때 루틴에 전달되는 조건에 따라 수행하는 기능이 다를때 발생

예를들자면 입력폼에서 이름과 연락처를 받는 input 에서 onChange 이벤트 함수에 대해서 동일한 함수를 활용해서 처리하는데 이때 전화번호일경우 다른 로직을 수행하도록 하면 이 onChange 는 논리적응집도를 갖고 쉬운말로는 하나의 메소드가 하나이상의 기능을 갖고 있다고 볼 수 있습니다. 

때문에 분리하여 기능적 응집도를 갖도록 분리해야한다.

 

우연적 응집도

의도적인것이 아닌 놓을곳이 없어서 발생하는 응집도

대표적인예가 utils 라는 폴더

 

높은응집도 

이해하기쉽고

의도를 파악하기쉽고

테스트하기 쉽다.

 

커뮤니케이션에도 적용할 수 있다. 

프론트개발자가 서버개발자에게 응답에러에 대한 파악을 할때 서버에서 에러를 파악하기위해 필요한 모든정보를 한번에 전달하여 필요한 응답을 한번에 전달받을 수 있다. 

 

커밋에도 적용할 수 있다.

PR 을 요청할때 커밋을 통해 해당 PR에 대한 내용을 파악 할 수 있는데 만약 PR 과 상관없는 내용이 커밋에 포함되어 있다면 해당 내용에 대해서 파악하는데 어려움이 있을 수 있다.

 

목적에 맞게 필요한 만큼의 응집이 필요

 

응집도는 컴포넌트를 나누는 기준이 될 수 있다.

 

정리

최근 컴포넌트에 대한 고민을 많이 하고 있습니다. 아토믹 디자인 패턴도 사용해보고 MobX 를 적극적으로 활용하여 비즈니스 로직을 분리해서 사용해보기도 했습니다. 그러나 뭔가 근본적인 문제 해결은 되지 않는다는 생각이 있었고 팀원들에게도 뭔가 명확한 이유와 문제점을 제시하면서 개선에 대한 요구를 말하기가 어려운점이 있었습니다. 

 

인사트를 얻었던 두 내용은 따로볼것이아닌 하나로 묶어서 보고 생각하면 더 좋을것같다 라는 생각이 들었고 현재 고민하고 있는 부분과 연관성이 있는 내용들이라 정리하게 되었습니다. 

 

문제제기와 그것을 해결하기위한 명확한 정의 그리고 친절한 예시들 덕분에 회사에서 작성했던 코드들중 문제가 있다라고 생각되었던 코드들을 대상으로 대입해보고 생각하면서 내용을 들을 수 있었습니다. 

 

관심사와 의존성, 응집도는 결국 하나의 지점을 향하는 문제해결방법이라는 생각이 들었고 그것은 결국 리액트에서 컴포넌트를 어떻게 분리하고 어떻게 관리할것인가 라고 생각합니다. 

 

현재 회사의 서비스중에 가장 중요한 기능중에 하나가 계약서 작성 부분입니다. 몇번의 개선과정을 거치긴했지만 여전히 테스트하기는 어렵고 로직은 복잡하고 연관성 없는것들끼리의 응집도는 높은상태입니다. 기능상 동작에 대한 이슈는 없지만 언젠간 곪아서 터질 부분이라고 생각하기때문에 개선이 시급한 부분이 있습니다.

 

다만 내부적으로 우려되는 사항은 리팩토링이나 코드개선이 진행될때 안정적이지 못했다는것입니다. 이로인해 리팩토링이나 내부적 코드수정 개선에대해 신뢰성을 주고있지 못하고 있습니다. 이미 잘 동작하고 있는데 외부적으로 변경되는사항은 없는데 괜히 코드를 수정해서 없던 문제도 발생시키고 이미 QA 도 다 끝난 사항에 대해서 다시금 테스트를 진행해야 한다는것이 장벽으로 남아있습니다.

 

때문에 현재 하고자 하는 개선작업에는 두가지를 최우선으로 고려해서 진행해야하고 그럴러면 제대로된 설계와 테스트환경이 갖춰져야 합니다. 

1. 모델과 관심사를 재정의하고 명확한 기능적 응집도를 갖게하기위한 리팩토링이 되어야 한다.

2. 타 부서의 신뢰를 얻어야한다 그럴려먼 기존에 잘 동작하던건 그대로 동작하게 만들어야한다.

 

이 과정을 통해서 더 좋은 코드를 생산하는 개발자가 되고 동료들에게는 신뢰를 주며 내가 받은 인사이트를 다른 동료 개발자들에게도 전달할 수 있는 그런 시간이 되기를 희망해봅니다.

 

 

추가자료

컴포넌트 제대로 만들기

컴포넌트 제대로 만들기

컴포넌트의 역할 분리

컴포넌트의 역할 분리