혼란 요인 예시
위 코드 예시에서
UserMainPopup은 일반적으로 어떻게 해석될까?코드만 봤을 때 개인적으로 드는 생각은 다음과 같았다.
- 리액트 컴포넌트의 return 문에 있으니까 UI겠다.
- 컴포넌트 명이 Popup이라고 명시되어 있으니까 팝업 모달의 형태를 보려면 저 코드를 봐야겠구나
- 팝업을 제어하는 부분이 밖으로 빠져있진 않네? 팝업을 제어하는 부분도 내부로 넣었나 보다. 팝업 제어 로직을 보려면 컴포넌트 내부를 봐야겠다.
컴포넌트 파일 내부
실제 코드 내부를 보니 생각했던 것과 많이 달랐다.
코드 내부를 보기 전에 추측했던 요소들이 얼마나 부합되는지 맞춰보자
- 리액트 컴포넌트의 return 문에 있으니까 UI겠다.
- ⇒ 단순히 빈 프래그먼트를 반환하므로, UI가 아니다.
- 컴포넌트 명이 Popup이라고 명시되어 있으니까 팝업 모달의 형태를 보려면 저 코드를 봐야겠구나
- ⇒ 실제로 화면에 보여지는 모달은 여기에 정의되어 있지 않다. 따라서 이것도 틀렸다.
- 팝업을 제어하는 부분이 밖으로 빠져있진 않네? 팝업을 제어하는 부분도 내부로 넣었나 보다. 팝업 제어 로직을 보려면 컴포넌트 내부를 봐야겠다.
- ⇒ 일부 맞지만, 현재 코드만 보고 로직을 확신할 수 없다.
- 코드 해석 순서대로 나열해보면 다음과 같다.
이펙트가 동작할 때마다인덱스를 증가시키네?인덱스로 뭘 할까?- 인덱스에 따라 훅의
willSkip파라미터가 바뀌네? 뭔가 쿼리를 호출하는 건가? useGet@Modal이라고 되어있는데 모달은 반환되지 않고,hasPopup불린 값만 반환되네?hasPopup으론 뭘할까?- 값을 리턴하는 것도 아니고, 단순히 이펙트로 인해 다음 인덱스로 증가할 뿐이네?
팝업은 어디서 뜨는 거지? 훅 내부까지 봐야겠다.
결국 얻은 것은 뭔가 인덱스에 따라 순차적으로 뭔가가 처리되는구나 정도의 정보만 얻을 수 있었다.
정작 내가 궁금했던 팝업을 어떻게 띄우고, 팝업의 모양은 어떻고 등의 정보는 또 다른 세부 코드를 봐야만 알 수 있는 상태다.
보고싶은 부분만 명확하게 볼 수 없고, 전체 코드를 해석해야만 한다는 건 정말 좋지 않다.
생산성을 크게 저하시키는 요인 중 하나다.
훅 파일 내부
문제
UserMainPopup의 내용을 이해하려면 코드 전체를 파악하고, 그 흐름까지 정리한 뒤에나 파악할 수 있다.
- 절대 그 전에 뭔가를 알 수 없고, 모든 퍼즐이 맞춰질 때까진 계속 혼란을 준다.
- 심지어 코드를 한번 파악한 후에, 시간이 지난 뒤 다시 해당 코드를 볼 때면 또 같은 혼란을 겪는다. (기억이 희석되므로)
물론 핵심을 얼핏 기억하고 있을테니 이전보단 파악하는 속도가 빨라지긴 할테다. 하지만 이는 올바른 코드 설계를 했다고 볼 수 없다. 전혀 클린하지 않다.