component와 hook 에 적용한 SOLID - [hook 편]

목차

1. SOLID 원칙 - FrontEnd에 적용이 가능할까?
2. 내 코드 의존성의 원인
3. 해결 방법 - component 또는 hook이 알아야 하는 정보 줄이기 (S: 단일 책임 원칙)
4. 잘못 설계하는 과정 (실제 예시) - 어떤 컴포넌트를 만드는지 알려줄 거에요.
5. hook이 담당하는 데이터를 최소한 작게 분리해서 생각해보기 - 의미 덜어내기
6. hook 분리의 장점 (O: 개방 폐쇄 원칙)
7. 컴포넌트와 컴포넌트 hook과 hook 간 최소한의 소통 통로 (I: 인터페이스 분리 원칙)
8. 수정된 설계 과정 (실제 예시) - 어떤 컴포넌트를 만드는지 안 알려줄 거에요.
9. 추가된 요구사항 (실제 예시)
10. 잠깐 component이야기를 해보자. 렌더링에서 예상치 못하게 의존성이 문제가 되는 지점 - map 메서드 고찰 (I: 인터페이스 분리 원칙 위배)
11. 이것으로 SOLID 일부 적용 가능! - *D는 컴포넌트 편에서 추가됩니다

 

1. SOLID 원칙 - FrontEnd에 적용이 가능할까?

설계 원칙 SOLID는 프론트에서는 적용이 불가능 한걸까?

 

이전부터 들었던 생각인데

 

단일 책임 원칙,

개방 폐쇄 원칙,

리스코프 치환 원칙,

인터페이스 분리 원칙,

의존성 역전 원칙

 

이 모든건 프론트엔드 작업에서도 유지보수에 꽤나 유용할 것 같았다.

물론 예전에도 멘토님이 의존성에 대해 해주셨던 말씀을 잊지 않고 간직하고 있었지만, 의존성이 문제라는 것을 이해했는데... 의존성을 분리하는 방법을 몰랐다. 컴포넌트와 훅 모두.

 

그리고 전부터 '데이터'에 대한 고민도 마음에 품고 있었다.

어떤걸 묶어서 같이 가야 하는 거지? A 페이지에는 이렇게나 많은 데이터가 있는데..

모두 객체로 묶는건 정말 이상하고 렌더링도... 머리가 복잡해..

 

조립해서 사용한다는 건 정말 어떤 조각들도 잘게 분리되어야 하고, 서로간 의존하지 않아야 한다는 건데

생각보다 코드로 나타내보면 초보인 나는 엄청 많이 상호 의존적인 코드를 작성하고 있었다.

아무리 '작은 단위'로 설계 하더라도. 그리고 특히나 그런 경험은 map을 사용하는 컴포넌트에서 너무나 확연히 드러난다.

 

다만, 검색을 해보면 SOLID 대부분은 JAVA로 된 예시가 많아서 프론트엔드 JavaScript에 적용하는 방법을 고민했는데

의외로 개인 프로젝트를 하며 유지보수에 대한 진지한(...) 고민을 하다가, component와 hook에도 이 원리들을 적용해 볼 수 있을 것 같았다.

 

이번 글은 hook을 설계하며 생각을 정리한 내용입니다~!

2. 내 코드에 있던 의존성의 원인

몇몇 글을 읽어보다가, 어떠한 사실을 알게 되었는데 (글로 배운 업무 이해~랄까~)

[회사]에서 [업무]를 하다 보면 '컴포넌트'를 담당하는 사람과 '로직'을 담당하는 사람이 따로 존재 한다는 것을 알았다.

물론 그렇지 않을 수도 있지만,

이건 정말 매우 매우 매우 신선한 충격이었는데

 

나에게 있었던 문제는

1. [팀 프로젝트]를 진행하면 A 컴포넌트/혹은 페이지를 담당하며 A컴포넌트/혹은 페이지의 A 로직을 같이 담당하게 된다.

2. 그러면 A 컴포넌트/혹은 페이지는 A 로직과 강력한 결합을 하게 되는 자연스러운 과정을 따른다.

 

이러면, 오로지A 컴포넌트만을 위한 A 로직이 됨. 재사용 못함

 

정리해보면,

상태와 컴포넌트 간 의존성은 특정 컴포넌트에 꼭 맞는 상태(state)를 만들려고해서 생긴 문제라고 생각한다.

고민 끝에 내린 결론은

아주 작은 단위의 컴포넌트라고 하더라도, 하나의 상태로 컴포넌트를 구성하지 않고 조합해서 사용해보자는 생각을 하게 되었다.

작은 단위의 컴포넌트가 만약 '가공된' '어떤 의미'를 포함한다면,

- 처음부터 '어떤 의미'를 갖는 상태를 만드는 것이 아니라,

- 데이터를 분리해서 갖고있고(hook), 그 데이터를 재구성해서(hook조합) '어떤 의미'를 만들어 내는 과정이 필요한게 아닐까

아 물론 아주 작다는 것은.. 조각 단위가 아니라 크기 자체를 말한다.

음 다음에 나올 예시이기도 하지만 12px by 12px 정도만 해도 꽤 작은크기라 생각함.

 

물론 여태 내가 제대로 된 설계를 하지 않은 것도 문제지만,

문제를 문제라고 눈치채기도 힘들었던 것도 문제가 아닐까..

반성중

 

3. 해결 방법 - component 또는 hook이 알아야 하는 정보 줄이기

이야기가 길어졌는데, 본질은 서로를 몰라야 한다는 것(그 편이 초보한테는 받아들이기가 더 쉬운 것 같다)

즉, 너무 많은 정보를 알고 있는게 오히려 문제를 어렵게 만들었다.

여기서 SOLID 의 단일 책임 원칙을 적용할 수 있다.

 

전부터 '단일 책임'이라는 것을 '어떻게' 실현할 수 있는지 정말 궁금했다.

 

실제 예시는 백엔드가 많아서 잘 떠오르지 않는데, 프론트에서도 가능한건가..

진짜로 단일 책임이라는게 가능한가?

책임을 구성하는 단위는 어떻게 ?? 나눌 수 있는거지? 기준이 뭘까?

그렇다고 하더라도, 함수... 에서는 어떻게든 책임을 나눠볼 수 있을 것 같은데 '함수'에서만 가능한건가?

 

내가 내린 결론을 미리 적어보자면,

프론트에서도 가능한 것 같다. 컴포넌트 훅 모두

단일 책임을 가능하게 하려면, 데이터를 raw한 상태로 생각하는게 도움이 되는 것 같다.

책임을 구성하는 단위는.. 가장 raw한 상태는 데이터 그 자체이고, 그 다음이 데이터를 조립해서 얻는 새로운 의미를 가진 데이터인 것 같다. 이 부분  부터는 작성하는 사람이 의미를 부여하면서 달라지게 되는 것 같다.

함수 뿐만 아니라 컴포넌트랑 훅 모두에서 가능하다고 생각한다. 컴포넌트는 조금 더 여러가지를 고려하면 된다.

 

4. 잘못 설계하는 과정: 어떤 컴포넌트를 만들지 알려줄 거에요.

컴포넌트에서 (초보인 내가) 아주 쉽게 진행 할 수 있는 잘못되는 과정을 생각해보자.

 

그 전에 몇가지 올바르게 행해져야 하는 사실들을 짚어보자면,

1. 컴포넌트는 '작은 컴포넌트' + '작은 컴포넌트' + '작은 컴포넌트'  ... + '작은 컴포넌트' 의 조합으로 이루어진다.

(재사용성을 높이기 위해 작은 단위로 설계합니다)

2. 이 때, 같이 가야 하는 데이터, 즉 hook (안에 있는 상태)도 조합해서 사용해야 한다.

예를 들어 

이처럼 '응답 위치'를 나타내는 컴포넌트가 있다. (캐러셀 밑에 몇번째 요소인지를 나타내는 컴포넌트와 비슷한 역할을 합니다.)

그런데 여기서 그치는게 아니라, 이 응답 위치는 '사용자의 선택'에 영향을 받는다.

(간단히 말하면 문제풀이에서 오답/정답 상태를 표시하는 컴포넌트 입니다. 선택이 맞았다면 초록, 선택이 틀렸는데 다시 풀어서 맞았다면 노랑)

그래서 간단하게 로직을 생각해보면,

1. 사용자 응답 (틀린답, 정답)

2. 현재 문제 번호(현재 위치-초록색)

이렇게 나타내 볼 수 있는데, 이걸 하나의 hook안에 로직을 다 넣으면서 hook은 단일 책임 원칙을 위배하게 된다.

그러면 그냥 당장은.. 더 큰 컴포넌트에서 이 문제점이 슬슬 드러나기 시작한다.

 

중복 로직이 우후죽순으로 발생하고, 어떤 데이터는 분해해야 하고...

 

1과 2로 나눈 것도 각각을 hook으로 분리할 수 있다. 사실 어쩌면 이것도 배열과 인덱스에 의존적이긴 할지도...

1의 사용자 응답 hook은 오답/정답을 나누지도 않아야 한다.

사용자 응답만 있으면 된다. 그래야 다른 hook의 상태(state)와 결합해서 '조립'을 할 수 있는 작은 단위로 사용할 수 있다.

 

예를 들어

위처럼 [오답, 정답, 정답, 정답, 오답, 정답. . .] 이렇게 표현을 하려면

일단, 문제 정답이 필요하다. 정답이 있어야만 사용자 응답이랑 비교할 수 있으니까.

그러면 문제 번호도 필요하다. 어떤 문제의 정답인지도 알아야 하니까.

그러면 어떤 문제인지, 그리고 정답과 비교하는 로직도 추가된다. 저 작은 hook에 작지 않은 로직이 추가되는 것.

 

앞에서 말했던 내용을 다시 떠올려보면,

작은 단위의 컴포넌트가 만약 '가공된' '어떤 의미'를 포함한다면,
- 처음부터 '어떤 의미'를 갖는 상태를 만드는 것이 아니라,

 

여기서 오답/정답은 그 자체로 어떤 의미를 갖는다. 몇 번을 선택했는지, 그 번호는 정답이랑 일치하는지 불일치하는지.

그런데, 사용자 응답은 정말 날것 그대로의 응답만을 의미한다. 1번을 선택, 2번을 선택, .. 정말 그대로 사용자가 입력한 내용을 받는 것.

 

처음에는 오답/정답 로직을 그대로 hook에 넣었는데, 이렇게 사용하면 상위 hook에서는 응용하기가 어렵고, 오히려 이 내용을 쪼개서 뭘 하려는 나를 발견했다. 그래서 너무... 고통스러웠는데...

방법이 없을까 생각해 보다가, 관계형 데이터베이스에서 데이터간 연관성을 잠깐 떠올려봤고, 상태 데이터를 이런 방법으로 분리하고 조합하면 어떨까 생각해보면서, 상태가 갖는 책임을 분리할 수 있을 것 같다는 생각이 들었다.

물론 오버엔지니어링도 생각안한 건 아니지만.. 

5. hook이 담당하는 데이터를 최소한 작게 분리해서 생각해보기: 의미 덜어내기

다시 돌아와서, '사용자 응답' 만 hook에 보관한다면 어떨까

(여기서는- 수능처럼 5지선다라고 해보자. 총 5개의 선택지가 존재한다. 그냥 어떤 응답을 했는지만 OMR에 남긴다.)

 

[1번, 2번, 4번, 3번, ... 5번, 3번]

이러면 hook에서는 상태를 변경하는 함수만 있으면 된다.

상태를 변경한다는 건 배열에 추가하는 것인데, 이 로직은 외부에서는 알 필요가 전~혀 없다.

그냥 어떤 응답을 했는지만 hook에 전달하면 된다. 매개변수에는 '몇 번' 인지 만 전달한다. 상세 구현은 사용자 응답 hook안에 갖혀(?)있다.

 

그리고 hook에서 반환(return ) 하는 건 사용자 응답과 상태를 변경하는 함수!

그러면? 그러면 정답을 판단하고, 그 다음 색상을 표현하는 함수는???

이는 사용자 응답 hook의 외부에서 조립해서 사용해야 한다.

 

여기서 눈치채야 하는 건, A라는 작은(...내가 생각할 때 저 동그라미들은 충분히 작다...) 컴포넌트가 단 하나의 훅만을 사용하는게 아니라는 것이다.

그래서 아까 언급했듯이 컴포넌트를 아예 모르면 좋은데, 어떤 기능을 갖는지를 이미지화 하면 그 데이터(여기서는 오답/정답 여부)에 쉽게 영향을 미치는 것 같다..

 

[회사]에서 [업무]를 하다 보면 '컴포넌트'를 담당하는 사람과 '로직'을 담당하는 사람이 따로 존재 한다는 것을 알았다. 

 

정리해보자

1. 컴포넌트와 hook(로직)을 분리해서 생각해야 한다.

2. 작은 단위의 hook에서 기본 로직을 제외한 어떤 판단 (if문 등)을 하고 있다면, 데이터를 더 분리할 수 있는지 생각해볼 수 있을 것 같다.

3. 하나의 상태가 어떤 가공된 의미를 갖고 있는지 생각해보기

 

컴포넌트의 이미지를 알고 기본 로직이 어떻게 되는지 내가 이미 알고 있다면~

초보인 나는 거대하게 설계하는 단계로... 진행시켜! 하게 됨

 

6. hook을 분리했을 때의 장점

1. hook을 쪼개서 사용하면 클래스처럼 붕어빵 틀로 사용할 수 있다.

2. 그리고 함수도 기능에 따라 분리할수도 있고

3. hook에서 반환되는 인자의 범위를 아주 작게 설정하면, 수정해야 할 다른 컴포넌트나 hook의 범위도 줄어들게 된다. SOLID 관점으로 보면 ocp 개방 폐쇄 원칙을... 말할 수 있을 것 같다.

4. 그리고 상위 hook에서 하위의 hook을 사용하면 함수마저 추상화가 가능해서, 상위 hook에서 생성한 함수는 매개변수가 하나도 없는 함수를 만들 수도 있다.

5. 코드가 퍼져나가는 범위를 좁힐 수 있다. return하는 부분은 조각 함수를 내보내지 않고, 함수 묶음을 내보낸다. 따라서 코드를 몇 단계의 레벨로 나눌 수 있고, 그렇기 때문에 수정 범위가 좁아진다.

 

5번을 더 자세히 말하자면, 현재 컴포넌트에서 '필요 없는' 레벨은 노출하지 않는다는 것이다.

흠. 실제 예시로 들어보면, '문제를 출제하는' 컴포넌트는 사용자가 그냥 어떤 선택지를 선택할지만 알면 된다는 것인데, 사용자 응답에 push하는 코드를 노출 시킬 이유가 없다는 의미이다.

 

사용자_인터렉션_함수(){

 응답_추가_함수( ... )

 정답시_다음문제_호출_함수(...)

 ... 등등

}

 

여기서 return 하는건 사용자_인터렉션_함수 하나이다. 나머지 함수들은 묶음이어서 다같이 움직인다.

 

이렇게 코드를 레벨별로 쌓아나가면, 최상위에서는 사용자 인터렉션에 관한 함수만 내보낼 수 있다.

범위 안에 가둔다는 말인데, 이러면 밖에서 유지보수할 일도 없고 중간 레벨에서도 함수만 빼고 더하고 하면 된다.

 

7. 컴포넌트와 컴포넌트 hook과 hook 간 최소한의 소통 통로

그리고 여기서 내가 느꼈던 점은

아주 초기에 .. 이런 구조를 흐릿하게나마 느낌으로 받아들였을 때

음.. 계단식이라는 느낌을 받았던 것 같다. 아니면 모래시계 느낌. 아 물론 그 추상적인 형태를 보고 떠올린 느낌인데..

 

hook을 쌓아 올려야 한다는 점에서 계단이라고 느꼈고 (그런데 컴포넌트에서 컴포넌트로 내려줄 때는 또 내려가는 계단)

또.. 컴포넌트에 prop으로 주입할 때는 '필요한 것'만 넣어야 했기 때문에 모래시계의 그 좁은 부분이라고 느꼈던 것 같다.

모래시계는 앞에서 말한 재사용과는 또 다른 주제인데, SOLID 관점에서는 I 느낌? 인터페이스 분리 원칙을 적용해야 한다는 것처럼 느꼈다.

 

(아래에 인터페이스 분리 원칙을 위한 map 예시가 준비되어 있습니다~!)

 

8. 수정된 설계 과정: 어떤 컴포넌트를 만드는지 안 알려줘요.

그리고 그 모래시계는 하나가 아니다 라는건 내 착각일지도 모르지만 이 설계가 맞는지 확실한건 아니지만..

예를 들어보면

'hello-kk님의 성적 분석'이라는 컴포넌트는 'N'과 'M'이라는 컴포넌트로 구성되어있다고 해보자.

그림으로 구체적으로 예를 들면

'hello-kk님의 성적 분석'이라는 컴포넌트는 위에서 예시를 들었던 문제풀이에 대한 오답노트다. 그리고 'N' 이라는 컴포넌트는 '문제' 컴포넌트는 한 문제에 대한 오답정리이다. 'M' 은 ??? 컴포넌트이다.

 

그리고 문제 번호랑, 사용자 응답이 prop으로 보내졌다.

..그런데 여기서도 'hello-kk님의 성적 분석' 컴포넌트 안에 '문제'라는 컴포넌트가 있다는 건 잊어야한다고 생각한다. 의존성을.. 분리해서 생각하려면

 

자 그러면 시작해보자.

위에서는 'A컴포넌트'에 대해 미리 설명을 했고, 로직이 자연스럽게 떠올랐다.

4. 잘못 설계하는 과정: 어떤 컴포넌트를 만들지 알려줄 거에요.

 

그런데, 이번에는 '문제'라는 컴포넌트 안의  'M'은어떤 컴포넌트라고 설명 하지 않았다. 즉  'M'에 어떤 prop을 전해주어야 하는지 조차 모른다.

이렇게 'hello-kk님의 성적 분석'컴포넌트에서 'M'이라는 컴포넌트의 의존성을 끊어낼 수 있다. (녜???)

의존성을 끊어내는 건 (내 생각에) 자식 컴포넌트로 넘겨주는 prop을 부모 컴포넌트가 갖고있지 않으면 되는 것 같다.

(그러면 여기서 드는 생각이, 아니 그러면 prop을 어떻게 넘겨주지? 인데, component 편에서 계속됩니다.)

 

이제  'M'이라는 컴포넌트를 설명해보면,  'M' 에서는 'N' 이라는 '문제'가 포함하고 있는 이미지를 그려야 하는 컴포넌트이다.

갑자기 뜬금없이 이미지?

 

굉장히 뜬금없다고 느껴지는데, 프로토타입 만들다보니 알겠다. 그냥 요구사항이 확확 바뀐다.

더 좋은 생각이 날 때마다 반영해야 한다.

그런데 그건 뭐가 될지 모른다. 랜덤박스임

 

그런데 이미지 '정도' 라면, 그냥 prop으로 넘겨도 되는 거 아닌가? 생각할 수 있고 그냥 옵셔널로 전달하면 되는거 아닌가? 생각할수도 있다.

뭐 지금이야 프로토타입이고 MVP니까 prop이 작지만. 나는 내 코드에서 본 적 있다. 몇 줄 씩이나 차지하는 props들을

앞으로 벌어질 일들을 생각하면, 정말 이 하나의.... prop 추가가 엄청난 수정을 요하게 된다는 것을 알게 된다... 여기저기 다 수정해야 함

 

여기저기 prop이 있어

oh~ no~ 

Charlie Puth - Left And Right ft. Jungkook of BTS

 

9. 추가된 요구사항 (실제 예시)

여기서 기능이 추가된다고 생각해보자.

하하하 벌써부터 떨리는걸~ 어디까지 수정하게 될지~ 살려줘...

 

- 이미지가 1개가 아니라 2개라면?

- 문제 풀이 설명을 해야 하는데, 이미지가 어떤 이미지인지 설명해야 해서 이미지에 제목을 달아야 한다면?

- 그리고 만약 이미지에 설명이 추가된다면?

 

벌써부터 수정할 생각에 마음이 웅장해진다.

 

[prop으로 이미지를 전달한다고 할 때의 수정 과정...]

[그림-1] 모래시계 형태

[그림-2] 계단 형태

(1) 이미지가 1개가 아니라 2개라면, 컴포넌트의 prop에 배열이든, 하나의 이미지 prop을 더 추가해야 한다.

그리고, hook에서도 이미지를 하나 더 전달해야 하기 때문에, 그 hook도 수정해야 한다.

(2) [그림-*] 이라는 정보를 추가해야 한다면, hook에서 반환하는 부분도 수정해야 하고, 컴포넌트에서 이미지 제목에 대한 prop을 추가해야 한다.

(3) *형태 라는 정보를 추가해야 한다면 hook에서 반환하는 부분도 수정해야 하고, 컴포넌트에서 이미지 설명에 대한 prop 을 추가해야 한다.

 

여기서 헷갈리면 안되는 부분을 다시 짚어보면 여기서 말하는 컴포넌트는 '1개 문제'에 대한 컴포넌트가 아니라, '10개의 문제를 렌더링하는 오답노트'를 의미한다. 물론 그렇기 때문에, 이 컴포넌트에서 하위 컴포넌트로 또 prop을 내려준다면 하위 컴포넌트도 수정이 필요하게 됨. 타입스크립트를 사용하면 타입도 추가하고 ..

 

예를 들어,

'hello-kk님의 성적 분석' 컴포넌트인거지,

'1번 문제 결과' 컴포넌트가 아니라는 것.

[hello-kk님의 성적 분석]컴포넌트( { ...props, 이미지} ) 

[1번 문제 결과]컴포넌트( { ...props, 이미지} ) 

이런 식으로 prop을 추가해야 한다. 이는 수정을 아주 어렵게 만들고 여기저기 고쳐야 할 부분이 많아져서 아주 골치아프고 이미지 prop에 의존적인 형태로 흘러가게 된다.

 

10. 잠깐 component이야기를 해보자. 렌더링에서 예상치 못하게 의존성이 문제가 되는 지점 - map 메서드 고찰

생각해보면 오답노트는 한 문제가 아니다. 

10개 문제에 대한 오답을 작성해야 한다면, map을 순회해야 하는데

map을 순회 할 때 실제로 이미지라는 prop이 필요한지를 생각해보면 된다. 차근차근 해보자.

 

이건 컴포넌트 설계에서 가장 많이 했던 고민인데, 컴포넌트에서도 의존성을 끊어내는 방법이 따로 있다.

map이라는 건 어떤 컴포넌트를 여러번 반복해서 렌더링하는 구조이다. 그냥 어떤 걸 반복하기만 하는, 일종의 .. 중간.. 단계?

여기서 책임 분리를 생각해보면 사실상 map 순회이지, 특정 컴포넌트를 순회하는게 아니기 때문에 렌더링을 하는 기능까지 생각하면 의존성을 분리하기 어려워진다. (이 내용은 컴포넌트 편에서 좀 더 다루도록 하겠습니다.)

간단하게 예시만 들어도, <>{items.map((item)=> <문제 컴포넌트  ...  />}</> 이렇게만 작성하더라도 map을 사용하는 컴포넌트는 그냥 문제 컴포넌트만 들어갈 수 있게 되어버린다. 문제 컴포넌트에 100% 결합되어 버린 것.

 

그리고 이 때 (나처럼) 잘못 사용하면 상위 컴포넌트에서 모든 prop을 꺼내서 냅다 들이 붓는다. (과거의 나 자신... 왜...?)

어쨌든 이것도 SOLID의 I에 해당되면서 인터페이스를 분리하는 원칙에도 위배되지만, 수정사항이 너무나도 많아지게 되는 결과를 초래한다.

인터페이스 분리 원칙은 (내가 봤을 때-) 프론트엔드 특히 컴포넌트에서는 사용하지 않는 prop은 배제하고, 사용하는 prop만 가지도록 하는 원칙으로 생각하면 .. 되지 않을까 싶다.

 

이걸 해결하기 위해서는 두가지가 있는데,

 

첫 번째는 컴포넌트가 위처럼 컴포넌트 안에 컴포넌트 컴포넌트 안에 컴포넌트 ... 구조를 갖더라도, 병렬적으로 생각해야 하고, 주입하는 부분에 의존하게 만들면 되는 것 같다. 위처럼 정말 그냥 각각의 컴포넌트는 서로를 모르면 된다.

(component 편에서 다루도록 하겠습니다)

 

두 번째는 hook에서 처럼 .. 데이터의 책임을 분리하는 것 같은데..

인터페이스 분리 원칙을 생각하면ㅡ 최상위 컴포넌트 prop이 하위 컴포넌트들의 모든 props를 가질 필요가 있을까? 싶었다.

왜냐면 이 오답노트 컴포넌트를 그리는데는 지금은 매우 간!딴! 하지만, 정말 뭔가 수정이 발생하고 추가 사항이 발생하면. 그 많은 prop을 다 갖는게 맞을까? 싶었기 때문인데, 그래서 앞에서 hook에서 했던 것처럼 역으로 데이터를 다시 쌓아가는 과정이 필요하지 않을까.. 생각했던 것이다.

 

그래서 떠올린게 모래시계 형태였다. 역으로 쌓아가니, 아래쪽 모래시계.

 

서로 아는게 많아지면, 유지보수가 어려워진다. 기능이 추가 될 때도 두렵다.

추상화, 조립, 책임 분리 ... 고민을 많이 하긴 했지만 

결국에는 '데이터'를 어떻게 다룰 것인지에 대한 고민을 계속 했던게 좀 다르게 생각해볼 수 있는 지점이었던 것 같다.

 

결론적으로는, 최소한으로 컴포넌트나 hook간의 소통 해야지만 수정 사항을 최소화 하고 생산성을 높일 수 있지 않을까 하는 생각을 하고 있다.

물론 이 방법이 실제 업무에서는 어떻게 다루어질지 .. 잘 모르기 때문에 확실하지는 않지만...

그리고 실제로 오버엔지니어링의 범위에 드는 걸까 하는 생각도 들기도 하지만

 

생각해볼 여지들은 많이 남은 것 같다.

그런데 이런 형태의 코드는 조립하기 쉽고ㅡ 의존성을 가능하면 줄이려고 하는 방향으로 생각을 해야 유지보수가 정말 쉽지 않나? 싶다.

그리고 개발 속도가 더 빨라진다. 처음에는 끙끙대며 고민하지만.

11. 이것으로 SOLID 일부 적용 가능!

D는 컴포넌트 편에서 다루면 좋을 것 같아서 제외했습니다.