20231120 퇴근 전 TIL

- 오늘 배운 점) 해당 상황에서 데이터를 어떻게 다루는지 + 앞으로 어떻게 확장할 가능성이 있는지를 고려해 여러 방안들 중 적절한 방법을 선택할 수 있어야 한다.

 

-> 오늘 드래그앤드롭으로 리스트의 순서를 변경하는 기능을 마무리하던 중, 코드리뷰를 받았다.

 

구현 상황) 백엔드에 리스트에 순서대로 id만 담아 배열로 전송하면 됌, 즉 배열 내의는 [1,2,3,4] 이런 식으로 1 depth

 

기존 코드) JSON stringify, parse를 이용해 깊은복사를 해 백엔드에서 초기에 받아온 배열을 복사 -> useState에 초기값으로 전달 -> 새로 만든 state를 순서가 변경될때마다 변경해줌 

 

개선 코드) spread 연산자를 통한 복사로 변경 

 

- stringify, parse가 연산 비용이 더 들어가기도 하고, 애초에 1 depth 만 복사하면 되는 상황이라 굳이 stringify, parse를 통해 복사할 필요가 없는 상황이었다. 순서 변경할때만 쓰는 배열이므로 배열의 구조가 바뀌거나 depth가 늘어날 일도 없는 부분이었다. 단순히 블로그에서 드래그 앤 드롭 구현한 레퍼런스들 찾다가 따라 쓴 코드였기 때문에, 무작정 따라쓰기보다는 코드 한줄한줄 내가 구현할 상황에 맞게 변경할 줄 아는 것이 필요함을 느꼈던 코드리뷰사항이었다.

 

- 오늘 배운 점) 단일 기능 컴포넌트에서 네이밍 보편화

 

구현 상황 / 기존 코드) LanguageTab 이라는 컴포넌트를 만들어, onChange, languageOptions를 props로 내려받아 옵션 내의 언어들을 바꿔주는 탭을 구현해두고, props를 onSelectedLanguageChange, selectedLanguageOptions 이런식으로 네이밍해두었었음. 

 

피드백) LanguageTab은 언어를 변경하는 단일한 기능만을 갖고있는 컴포넌트이기에, onChange, options 등 네이밍을 좀 더 보편화하여 사용해도 가독성이나 협업에 큰 문제가 없음. 따라서 이런 경우에는 네이밍을 보편화하는 것도 고려해볼 수 있다. 

 

 

=> 모든 것은 해당 코드가 어떤 상황인지를 명확히 파악하는 것이 우선되어야 함을 느꼈던 하루. 단순히 원칙을 적용하는것에만 집착하기보다는 해당 상황에서 그 원칙이 적용될 수 있는지, 어떠한 이점/단점이 있는지를 고려하며 코드를 짜는 습관을 들여야겠다!