프론트엔드 아키텍처 - How to Write Shy Code

요즘 회사에서 프론트엔드 아키텍처 관련해서 스터디를 하고 있는데, 내가 발표 맡은  How to Write Shy Code에 대해 정리하였다.

Shy Code

다른 모듈에 불필요한 것을 드러내지 않고 다른 모듈의 구현에 의존하지 않는 모듈

( ++ 이전에 읽은 오브젝트와 동일한 주제 : 각 객체가 자신의 책임을 자율적으로 수행하도록 설계하면, 협력 시 내부 구조 노출이 최소화된다. )

Orthogonality

x, y, z 좌표는 직교한다. 즉, 한 축을 가로질러 이동해도 다른 두 축에는 영향을 미치지 않는다.

소프트웨어에서는 '모듈 간에 영향이 최소화된 독립성'을 의미함.

The Law of Demeter

해당 법칙은 오직 당신의 친구에게만 말하라(Only talk to your friends)라는 구절로 요약된다.

= 결국 최소한의 독립성을 가져가라는 뜻과 동일.

“Thou shalt speak only to thy closest companions, for reaching into the depths of a stranger’s soul shall bring chaos to thy code as surely as I bring the winter when my tests flake on the release pipe lines.”

 

예를 들어 고객 지원 시스템에 아래처럼 세 가지 모듈이 있다고 가정해 보자.

이제 고객의 가장 최근 대화에서 가장 최근 메시지를 가져와서 어떤 식으로든 처리하는 함수를 작성한다고 가정해 보자.

 

customer에서 conversations 배열을 직접 꺼내서 마지막 대화를 찾고, 그 대화 객체에서 또 messages 배열을 꺼내 가장 최신 메시지를 찾고 있다. 결과적으로 결합도가 올라가고, 내부 구현을 바꿀 때마다 여러 군데를 수정해야 한다.

 

결국 위에서 설명한 디미터 법칙을 위반하고 있음을 알 수 있다.

실제로는 세 모듈 모두와 밀접하게 결합되어 있음.

그럼 디미터의 법칙에 충족하기 위해 해당 기능을 제공하는 메서드를 만들어서 분리해 보자.

고객(Customer) 객체가 "가장 최신 메시지를 찾아주는(findMostRecentMessage)" 메서드를 제공하면, 외부에서는 아래처럼 하나의 함수만 호출하도록 설계 가능하다.

내부적으로 Customer가 Conversations나 Messages에 어떻게 접근하고, 어떻게 날짜를 비교해 최신 메시지를 찾는지는 드러나지 않음.

해당 예시는 "Tell, Don’t Ask" 라는 객체지향 프로그래밍 원칙을 보여주는데, 객체에 필요한 데이터를 묻고 직접 처리하기보다, 객체가 해야 할 일을 지시하는 것이 낫다는 것이다. 이는 코드를 수줍게 유지하는 훌륭한 방식이고, 함수나 UI 컴포넌트, React 훅 등 어디든 적용 가능하다고 한다.
다만 이를 극단적으로 적용해 "메서드 체이닝을 아예 하지 말자" 라고 보는 건 너무 지나치다고 한다. 만약 같은 객체 소속 메서드들이라면 체이닝해도 무방하지만, 중요한 건  코드가 몇 개의 추상화 계층을 통과하느냐 인데 , 한 개는 이상적이고 두 개는 괜찮으며, 세 개 이상이라면 코드가 너무 많은 것을 아는 상태일 수 있다는 점을 유의해야 한다고 한다. 

 

🔥 결론 :  코드의 설계를 개선하고 변경에 강하게 만들고 싶다면, 좀 더 수줍게 만들어 보도록 하자. 🔥

 

적용 

해당 글을 읽고 지금 하고 있는 프로젝트의 코드를 간단히 리팩터링 해보았다.

 

기존에는 ColumnEdit 내부에 컬럼 리사이즈와 관련된 모든 로직이 포함되어 있었다.

 

해당 컴포넌트는 리사이즈 기능을 제외하고도 많은 기능을 관리하고 있어 state 가 많다.

실제 코드에서 리사이즈 관련된 상태는 widthPercnet, initalX, isResizing인데 widthPercnet를 제외하고는 initalX, isResizing는  변경된 너비 퍼센트를 계산하기 위한 State이다.

해당 컴포넌트에서 리사이즈 관련해서는 최종적으로 변경된 widthPercnet 값만 중요할 뿐, 다른 상태들을 알 필요가 없다.

 

따라서 리사이즈 관련된 로직은 따로 분리해서 훅으로 만든 결과  ColumnEdit은 훅에 어떤 작업을 해달라 (컬럼 리사이즈 등)고 명령만 하게 됨으로써 나머지 구체적인 로직들은 Shy~하게 캡슐화되었다. 

widthPercent 를 제외한 state 들은 훅 안에서 관리하도록 분리되었다.