들어가며

지난 Frontend Fundamentals 모의고사 1회차에 이어 이번에도 2회차에 참여했다. 지난번에 코드 관련해서 얻은 인사이트가 많아서 이번에도 기대를 갖고 참여하게 되었다. 2회차는 개발이 완성되어 있는 코드를 개선하여 리팩토링하는 것이 과제였다. 지난 번에 배웠던 내용을 기반으로 이번 풀이에 적용을 해보고 싶었는데 이 케이스에는 어떻게 적용하는 게 가장 좋을까?에 대한 고민이 가장 많이 들었다. 이 글에서는 배운 것들 중 다시 되새기며 짚어보고 싶었던 부분들에 대해 정리했다.

UI와 코드를 1:1 대응시키기

저번 회차에서 UI와 코드가 1:1 매핑되도록 하는 것이 코드 구조를 이해하기 쉽다는 것을 배웠다. 그래서 이후로도 이러한 기준으로 코드를 작성하고 있는데, 어디까지가 이 UI를 이해하는 데 필요한 로직일까에 대한 고민이 많았다. Select라면 Option도 이 컴포넌트의 관심사일까? map을 통해 카드 리스트를 렌더링한다면 관련 로직을 모두 엮어 CardList로 추상화할지 Card 컴포넌트를 생성하여 이 컴포넌트를 리스트로 렌더링 하는 로직을 표출할지 등 기준에 대한 고민이 많았다.

해설 강의를 보면서 들었던 생각은 이전에 들었던 ‘인터페이스 먼저 고민하라’라는 가르침을 제대로 수행하지 않았기 때문에 들지 않았나 싶었다. 인터페이스를 구상하는 것이 막막하고, 먼저 고민을 하더라도 막상 코드를 작성하게 되면 변경점이 많을 것 같다는 생각에 그대로 이행하지 못했던 것 같다. 그래서 해설 시작부터 인터페이스를 작성하시는 것을 보고 애초에 이렇게 접근을 했다면 내가 어디까지 코드를 이 컴포넌트에 둘지를 고민하지 않았을 거라는 생각이 들었다.

폼에는 필드를 설명하는 라벨이 하나 있고 하위에는 값을 입력하는 입력 필드가 하나가 존재한다. UI를 보면 모든 것이 하나의 덩어리다. 이런 것처럼 페이지 컴포넌트의 코드에도 이러한 구조와 같이 화면에 보이는 Label과 Input이 각각의 컴포넌트 덩어리로 깔끔하게 분리되는 것이 훨씬 더 이해하기 쉬운 코드 구조임을 느끼게 됐다. 그 전에는 이렇게 하면 너무 작은 단위로 많이 분리가 되는 것 같아 고민이 많았는데, 오히려 분리를 함으로써 코드를 찾아가기 쉬웠고 관련 로직만 모아 분리하니 페이지 컴포넌트에 너무 많은 관심사가 담긴 로직들이 얽히지 않았다.

네이밍

그동안에는 이벤트 핸들러라면 무조건 handle이라는 prefix를 붙여서 이름을 지었다. 그래서 handleClick, handleChange라는 네이밍을 많이 했는데 이는 충분히 함수의 역할을 설명하지 못한다. 버튼의 onClick 이벤트에 거는 함수라 해서 handleClick이라는 네이밍을 하게 되면 코드를 읽을 때 Click을 함으로써 어떤 로직이 실행되는지 함수의 내부 로직을 읽어야 이해를 할 수가 있다. 따라서 이와 같은 네이밍이 아닌 sendMessage와 같은 네이밍으로 리팩토링하니 코드의 흐름을 이전보다 더 쉽게 이해할 수 있게 됐다.

또한 인터페이스의 네이밍을 할 때 <DatePicker>라는 컴포넌트가 있다면 date와 setDate로 이름을 짓는 경우가 많은데, 이는 value와 onChange로 짓는 게 좋다는 이야기가 있었다. html의 인터페이스와 비슷하게 네이밍을 짓는 것이 이해하기 쉬울 뿐만 아니라, 결국 onChange 이벤트에는 setDate만이 아닌 다른 로직을 넣어야 할 때가 경우가 생기기도 한다. 따라서 이 컴포넌트가 사용될 곳에서 알아야 할 맥락만을 전달함으로써 setDate가 아닌 onChange라는 네이밍을 사용하는 것이 좋다. 이렇게 정말 필요한 맥락만을 남기고 덜어내는 것이 재사용성 또한 좋아진다.

네이밍에 대한 고민은 많이 해봤지만 정말 인터페이스의 이름까지 읽게될 사람에 대해 그동안 많이 고민해보지 않았다는 생각이 들었고, 인터페이스를 정의할 때 어떻게 정의해야 컴포넌트의 동작을 이해하기 쉬울까에 대한 고민을 많이 해야겠다는 생각이 들었다.

추상화

추상화가 필요할 때는 코드가 길고, 또 복잡할 때라고 생각을 해서 코드가 몇 줄 되지 않을 때는 분리할 때 굉장히 고민을 많이하게 됐었다. 그런데 해설에서 종택님께서 단순히 reverse 메서드를 사용하는 한 줄 짜리 로직이더라도 우리 프로젝트 맥락에서 그 로직이 highlight를 하기 위해 사용한다면 추상화하여 의미를 드러내는 것이 좋다고 말씀하셨다. 해주셨던 말씀을 그대로 옮겨 적은 것은 아니고 내가 이해한대로 적은 것인데, 큰 깨달음을 얻을 수 있었다. 결국은 읽는 사람을 위해 의미를 잘 드러내는 것이 목적임을 이해할 수 있던 말이었다.

마무리하면서

해설을 듣고나서 리팩토링까지 해보았는데, 이전에 고민이 많이 고민되어서 결론을 내리지 못했던 부분들에 대한 해답이 어느 정도 정리가 됐다. 코드에 절대적인 규칙은 없겠지만 좋지 않은 코드를 구별해내는 기준을 가질 수 있는 과정이어서 아직 2회차 밖에 참여하지 못했지만 만족도가 컸다. 지난 번에 배웠던 내용과 연장되어서 또 다른 깨달음들이 있었고 완전히 이해하지 못했다고 생각하지 못한 부분에 대한 이해도 할 수 있었던 시간이었다. 단순한 이론적인 배움에서 그치지 않고 실제로 개발을 하면서 바로 적용해볼 수 있는 깨달음이 많아 시야를 넓힐 수 있었다.