토스 Frontend Fundamentals 모의고사 후기 (2회차)

1회차 후기에 이어서 2회차 모의고사 후기를 쓴다.
1회차에서도 강조됐던 내용인데, 예측 가능한 코드를 짜야한다는주제가 이번에도 반복적으로 나왔다

사람 뇌는 코드를 "이해"하지 않는다

사람 뇌가 코드를 읽는 방식은 생각보다 단순하다. 한 줄 한 줄 의미를 분석하는 게 아니라, 함수명이나 구조를 보고 "이렇게 동작하겠지?"를 먼저 예측한다. 그 예측이 맞으면 넘어가고, 틀리면 그때서야 내부를 파고든다.
문제는 예측이 틀렸을 때다. 인지 강도가 급격하게 올라간다. 결국 가독성이라는 건 코드가 얼마나 "뻔하게" 읽히느냐의 문제다.

호출처의 관심사를 모르게 추상화한다

이번에 가장 신선했던 관점이다.

DatePicker 컴포넌트를 하나 만든다고 생각해보자. 이 컴포넌트에 date와 setDate를 prop으로 내려보내면 어떻게 될까?

 

일단 setDate라는 이름 자체가 "바깥에 date라는 상태가 있고, 그걸 set하는 함수다"라는 정보를 암시적으로 전달한다. 이 컴포넌트는 자기가 어디서 쓰이는지를 아는 셈이 된다. 여기까지는 별 문제 없어 보인다.

 

근데 요구사항이 바뀌면 문제가 커진다. 나중에 이 DatePicker를 URL 쿼리 파라미터 업데이트용으로도 쓰고 싶고, 폼 상태 관리에도 쓰고 싶고, 전역 스토어에도 연결하고 싶다고 해보자. setDate라는 prop 이름은 특정 사용처의 관심사에 묶여있기 때문에 다른 맥락에서 쓸 때 어색해진다. setDate인데 실제로는 URL을 바꾸는 거라든지, setDate인데 실제로는 zustand store를 업데이트하는 거라든지. 이름과 실제 동작 사이에 괴리가 생긴다.

 

반면 onChange로 받으면? 이 컴포넌트는 "값이 바뀌었을 때 알려주는 것"만 책임진다. 바깥에서 URL을 업데이트하든, 폼 상태를 바꾸든, 전역 스토어에 넣든 그건 호출처의 몫이다. 컴포넌트 입장에서는 모르는 게 맞다.

 

이번에 "호출처의 관심사를 모르게 만든다"는 관점에서 보니까 그 관례에 명확한 근거가 생겼다. setDate 같은 구체적인 이름을 prop으로 내려보내면, 그건 호출처의 구현 세부사항을 컴포넌트에 누출하는 거다. import는 없지만 일종의 암묵적 의존성이며 재사용성을 해친다.

 
결국 관련 없는 요소들을 분리하는게 인지 강도를 줄이는데 가장 중요하다는 생각이 든다.

후기

이번 모의고사 고민할거 진짜 많으니 안 풀어본 사람이면 한번 해보면 좋을 것 같다.
 
이번엔 아쉽게도 discussion이 활성화되지 않았다ㅠ
1회차때 연 discussion에는 많은 사람들이 본인들의 견해를 남기고 가셔서 재미있었는데 아쉽다..
https://github.com/toss-fe-interview/frontend-fundamentals-mock-exam-2603/discussions/89

페이지 간 flash message 전달 — location.state가 redirect에서 초기화되는 문제 · toss-fe-interview frontend-fun

 
그래도 이번엔 1회차보다 훨씬 뻔한코드에 가까워진 것 같다
https://github.com/toss-fe-interview/frontend-fundamentals-mock-exam-2603/pull/4

Feature by donghyun1998 · Pull Request #4 · toss-fe-interview/frontend-fundamentals-mock-exam-2603

 
1회차때 짰던 코드 보면 아주 냄새나는데, 지금 꽤 괜찮다고 생각한 이 코드도 6개월 후에 보면 끔찍했으면 좋겠다.
모의고사 100회차까지 계속 이렇게 성장하면 이론상 K 켄트백 삽가능