[TIL] 2023-0106 : 프리온보딩) 2주차 과제 제출, Custom hook과 관심사 분리

🐈오늘 배운 것

✔️2주차 과제 제출

이번 2주차 과제는 dnd 기능이 있는 이슈 트래커였다. 개인적으로는 dnd 기능을 만드느라 crud 구현을 제대로 하지 못했는데, 주말중으로 해당 부분을 완성하고 리팩토링해서 마무리할 계획이다. 

 

이번에 recoil 을 사용하면서 전혀 몰랐던 기능인 effects 나, selectFamily 같은 기능을 팀원들 덕분에 알게되었다. effects 란 함수를 배열에 의존성으로 전달하면 해당 effects 항목이 있는 atom state 가 업데이트 될 시 자동으로 그 함수가 실행된다. 예를들어 업데이트시 매번 localStorage에 접근한다면 적용해볼 수 있다.

 

selectFamily 같은 경우도 해당 state 에 업데이트가 있을 때 자동적으로 특정하게 처리된 값을 리턴하도록 할 수 있다. 우리 코드에서는 전체 배열에서 필터링을 거쳐 부분배열을 추출하는 코드가 있는데, 이 코드를 selectFamily 로 추상화하여 중복된 코드를 방지할 수 있었다. 팀원들 덕분에 recoil의 새로운 기능을 알게 되어서 좋았다. state의 변경을 useEffect 등으로 직접 감지하여 로직을 동작하도록 했었는데, recoil 자체적으로 이런 기능이 있어 추상화에 유리한 것 같다.

 

지금까지는 컴포넌트를 작성하면서 로직과 뷰를 구분할 생각을 잘 못했었는데, 이번 과제에서는 컴포넌트별로 폴더를 생성해 컴포넌트 파일, 커스텀 훅을 같이 저장하여 구현했다. 컴포넌트와 로직을 담당하는 훅이 분리되어 있으니 좋았고 또 한 컴포넌트에서 담당하는 기능을 알기가 더 직관적이고 개발하고 수정하기가 용이했다.

✔️Custom Hook과 관심사 분리

리액트에서 Custom Hook 을 사용하여 함수를 분리하는 것 또한 뷰와 로직이라는 관심사를 분리한 것이라고 볼 수 있다. 왜 이런 관심사를 분리하면서 코드를 작성해야 할까.

 

좋은 코드를 작성하기 위해서는 기본적으로 한 가지 모듈, 예를들면 한 가지 함수가 하나의 목적만을 수행하도록 해야한다. 이렇게 작성하는 이유는 해당 코드가 나중에 수정되더라도 수정하는 목적과 기능이 한 가지로 명확해지고, 다른 기능에 영향을 줄 확률이 적어지기 때문이다.

 

한 모듈이 여러군데에 영향을 주는 동작을 수행중이라면 어떤 곳에서 어떤 변화가 일어날지 예측하기가 어렵고 또 이 모듈이 정확하게 어떤 동작을 하는지 이해하기가 힘들어진다. 그래서 결국은 수정하기가 어려워진다. 변화에 대응하고 기능을 확장하고 계속 발전해나가야 하는데 그렇지 못하기 때문에 결국은 멈추게 된다.

 

리액트 함수형 컴포넌트의 custom hook 도 단순히 재사용을 위해서 만드는 것 뿐만 아니라 이렇게 뷰와 로직 즉 관심사별로 분리하기 위한 기능이라고 볼 수 있다. 또한 이렇게 로직을 분리하여 추상화를 하기 때문에, 실제로 어떤 상태를 변경하는 등 커스텀 훅을 사용하게 될 때 내부적인 구현이 사용 시점에는 중요하지 않게 된다.

 

여러 서비스에 걸쳐서 동작해야하는 코드를 횡단 관심사(cross-cutting concern) 라고 한다. 이 말은 오늘 처음 들어봤는데 이에 대한 가장 이해하기 쉬운 예시는 인증/인가이다. 즉 로그인이 되었는지, 로그인이 되었다면 권한이 있는지를 확인하기 위한 요청 코드이다. 어떤 요청이든 http 통신을 활용하고 이때 인증/인가를 위해 토큰을 전송한다. 이 통신을 위한 객체를 만들어서 추상화를 할 수 있다. 

 

이 http 요청 객체를 여러 서비스에 걸쳐서 다양하게 활용하려면 내부적으로 의존성을 가지고 있기 보다는 외부로부터 주입을 받는게 훨씬 더 유연한 대처가 가능할 것이다. 이를 의존성 주입이라고 한다. 내부적으로 어떤 의존성에 의해 코드가 실행된다면, 그 의존성을 외부에서 주입 즉 함수에서 인자를 전달하는 것처럼 클래스의 constructor를 통해 이 인자를 전달받아 내부 로직을 구현하도록 작성할 수 있다. 

 

이 횡단 관심사와 의존성에 대해 더 자세하게 작성하고 싶은데, 제대로 이해가 되지 않은 모양이다. 보강해야겠음.

✔️이력서 수정!

취업을 위해 이력서를 만들고 지속해서 수정중이다. 이력서의 어떤 부분이 부족한지 확인하기 위해 피드백도 받아보고 레퍼런스를 서치하기도 했다. 공통적으로 프로젝트에 대한 경험은 정량적으로 그리고 구체적인 근거를 제시하면서 자세하게 이야기 하는게 좋은 것 같다. 단순하게 이런 경험을 해 보았다가 아니라, 이것을 왜 했고, 이 기술을 왜 도입했고 그래서 어떻게 사용했고 어떤 결과를 얻었는지 - 그런 생각과 관점 그리고 결과를 중심으로 정확하게 서술할 필요가 있다. 이력서도 다른 사람에게 내가 어떤 사람이라는 것을 효과적으로 전달하기 위한 소통 도구이기 때문에 읽는 독자를 생각해야 한다.

 

✔️기타 - 블로깅에 대한 고민

블로그에 대한 고민도 있다. 현재 이 블로그는 개발 기록, 개인적인 경험을 기록하는 것에 초점이 맞춰져 있다. 다른 사람들에게 도움이 될만한 것들을 공유하는 것도 필요한데, 그럴만한게 트러블 슈팅, 에러 해결 방법인 것 같다. 그런데 그런 부분이 현재는 부족하다. 개인적으로 기록을 하고 있지만 그게 정리되고 공유가 되지 않는 것 같다. 겪을 때마다 글을 정리해서 포스팅하는 것은 무리가 있을 것 같고, 겪는 과정과 해결하는 과정을 상세하게 기록했다가 시간을 내어서 정리할 필요가 있는 것 같다. 

🐈Feedback

1. 머리가 잘 돌아가는 오전 시간을 활용한 것 good. 아침에 잘 되기 때문에 이력서 수정처럼 제일 자신없는 것을 오전에 하는게 좋다.

2. 프로젝트를 직접 개선할 수 있는 방법을 찾았다면 적극적으로 적용해보도록 하자.

🐈To Do

1. 의존성, Context API 에 대한 내용 공부

2. 과제 기능 구현 마무리 및 리드미 작성 - 가능하다면 회고

3. 모락모락 프로젝트 리팩토링 진행

4. 알고리즘 문제풀기

5. 데브매칭 과제풀기

6. JavaScript 비동기