[TS, REACT] TOSS 문제 리팩터링을 하고나서 느낀점

이전에 TOSS 문제에서 처참히 수준을 깨닫고 나중에 다시 풀어보겠다고 말을 했었다. 그리고 이번 스터디에서 단순 완성한 코드를 피드백받았는데,,
 
내 생각대로(?) 무수한 피드백을 받았다.

 

한분에게만 26개를 받았다

내 코드 자체가 워낙 다듬어지지도 않았고, 내가 봐도 굴러가기만 하는 누더기와도 같은 상태였기때문에
많은 피드백들을 받을 마음의 준비는 끝마쳐진 터라 사실 큰 충격을 받진 않았었고
 
오히려 저 날카로운 26개의 피드백이 나에게 너무 큰 도움이 되었다.
겸사겸사 피드백 주신분들의 코드를 보면서 이렇게도 짤 수 있겠구나 하는 아이디어도 많이 얻었던 것 같다.
 
지금은 1차 리팩토링을 마치고 수정점이 조금 남았는데 (근시일내로 마무리 지을 예정)
이번에 리팩토링하면서 느낀점들을 까먹지 않게 기록해보려고 한다.

 

리팩토링하면서 수정했던 사항들

커스텀 훅의 사용

문제 내용중에 모달 바깥을 클릭하면 모달이 닫히도록 구현하라는 부분이 있었다. 나는 해당 부분을 page에다가 몰아서 구현했는데,
해당 내용을 custom-hook으로 분리하면 더 좋겠다는 피드백을 주셨다.

 

리액트 커스텀훅(Custom Hooks)

1. 커스텀훅(Custom Hooks)란? 리액트는 구성 요소 전체에서 기능을 캡슐화하고 재사용하는 방법으로 커스텀훅을 사용합니다. 커스텀훅은 useState, useEffect 또는 useContext와 같은 하나 이상의 기본 제공

kubrickcode.tistory.com

잘 정리해놓으신 포스트가 있어서 이거로 디테일한 설명을 갈음하고, 간단하게 설명을 하자면
react에서 기본적으로 주어지는 hook 이외에 개발자가 직접 만드는 hook이 custom-hook이다.
 
custom-hook을 사용함으로서 얻을 수 있는 장점으로는
1. 코드가 더 간결해지고,
2. 유지보수가 더 쉬워지며,
3. 재사용성을 높일 수 있다.
 
확실히 이 부분을 적용하니 page가 상당히 깔끔해졌고, 더 가독성이 높아진 부분이 있었다.
지금까지 커스텀 훅에 대해서는 들어보기만 하고 직접 사용해 본 적은 없었는데, 이번 기회로 커스텀 훅을 직접 만들어 사용해보면서
앞으로는 이런 방식으로 로직을 분리해볼 수도 있겠구나 하는 생각이 들었다.

 

정확한 타입의 사용

이전에 작성했던 코드에서는 모르거나 정확하지 않은 타입을 any로 처리해버렸었는데, 이번에는 타입을 확실하게 표시해주었다
물론 이 부분은 effective typescript 스터디 할 때도 공부했었던 내용이지만, 타입체커가 유추 가능한 영역이라면 굳이 표시를 해주지 않아도 무방하다.
 
오히려 모든 부분에 타입을 표시하는것이 더 아마추어같은 코딩 방법이라고 하더라 (effective 말에 따르면 그렇습니다)
또, 내가 사용하는 webstorm에서도 그렇고 아마 vscode에서도 되는 방법이겠지만 커서를 올려놓으면 지금 어떤 타입으로 유추되고 있는지 표시해주기때문에, 타입을 확인해서 적어주면 되는거였기때문에 어렵지 않았다.
 
또 타입을 본격적으로 사용하면서 느낀 점이었는데, 기존에 사소하게 실수할 부분도 타입 자체에서 에러를 표시해주니까 이런 점에서도 확실히 휴먼 에러가 줄어들었음을 느꼈다.
 
effective에서 배웠던 타입 좁히기는 물론이고, 확실한 부분에선 타입 단언문으로 타입을 지정해주는 방법 또한 스무스하게 잘 익힌 것 같다.

 

역할의 분리 (추상화)

디자인 패턴 공부가 아직 마무리 되지 않았지만, redux 공부했을 때 기억을 되살려서 page - container - component 형태로 로직을 분리하였다.
 
물론 완전히 redux 디자인 패턴을 적용할 수는 없으니까 일부분 생각을 해서 변형을 주었는데,
page에서는 api로 받아온 데이터와 제출할 때 필요한 데이터를 담고있는 storage 관리, 그리고 모달 제어를 하도록 했고
container에서는 component에서 사용할 기능들을 담았으며, component에서는 오로지 렌더링만 하도록 로직을 구성했다.
 
물론 조금 더 추상화를 해야하는 부분이 남아있고, 단일 책임 원칙을 완벽하게 지키지는 못한 것 같으나
이전 로직보다는 나아졌다고 생각하고, 더 리팩토링하여 개선해볼 생각이다.

 

하드코딩 피하기

사용되는 상수들을 각자의 역할에 맞추어 분리해주었다.
예를들어 MESSAGE들이라던가, KEY라던가.. 이런 부분들은 하드코딩을 하기보단 따로 상수로 관리해주었다.
 
처음에는 별 생각없이 하나하나 선언했는데, 피드백도 그렇고 조금 더 생각해봐도 그렇고
비슷한 성격의 상수들은 객체로 묶어서 선언해주는게  더 낫다고 생각하여 이후 수정해주었다.
 
또 상수 데이터가 수정되지 않도록 Object.freeze();를 통해 불변성또한 가지게 해 주었다.

 


 

아직도 수정해야할 게 많고, 공부해야할 것이 많지만
한 주동안 리팩토링하며 얻어가는게 정말 많았던 것 같다.
 
이번에 토스 문제를 풀면서 더이상 자바스크립트는 사용하지 않을 것 같다는 생각이 들었다.
타입스크립트를 더 학습해야하는것도 있고, 타입스크립트에서 오는 사소한 휴먼 에러 방지가 정말 마음에도 들었다.
 
그리고 결정적으로, 이번 토스 문제 리팩토링을 진행해나가며 타입스크립트에 대한 자신감도 생긴 것 같아서,,
앞으로 한걸음 더 나아간 느낌이라 기분이 좋은 한주였던 것 같다.
 
피드백주신 스터디원들께 감사하다는 말씀을 드립니다 __b