오늘의 총평 ⭐️⭐️⭐️✨

유튜브를 보니까 하루를 기록하는 편이 좋다고 해서 TIL에 그에 대한 평가까지 더해서 기록하려고 한다. TIL을 작성하지 않은지 벌써 한달이 되어가는 것도 있고 해서 겸사겸사 다시 시작!

잘한 점

• 나름대로 오늘 게획한 할 일을 다 했다.
• 하기 싫은 일들을 하려고 해낸 점도 중요한 포인트 (리팩토링 책 읽기)
• 별 3개 반! 만족감에서는 4개 주고 싶기도

개선할 점

• 알고리즘 문제 풀기를 더 많이 하자

Recoil 심화 학습

Recoil이 단순하게 전역상태를 관리하는 패키지라고 생각했다. 그래서 initialization을 useEffect나 defaul값으로 처리해야 한다고 여겼다. 이런 단순함이 오히려 복잡한 로직이 필요없지만 상태를 공유하는 경우에는 간편하게 쓰일 수 있다고 생각했다. Redux도 사실 Redux-toolkit을 쓰면 사용할 만 하지만 괜히 복잡하다는 생각이 있어서 영 손에 잡히질 않는다.

여튼, 그런 줄 알았는데 이번에 Jest와 Testing-Library를 배우면서 테스팅을 Recoil 모듈에서도 적용하고 싶었다. 또한 리팩토링 책을 읽으면서 조금씩 내 프로젝트에도 진행해 보고 있는 와중에, Recoil은 어떻게 그것들을 적용할 수 있을까 싶어 공식 문서를 들여다 보았다.
오 그런데 Testing을 하는 방법과 effect를 recoil 내부적으로 처리하는 방법이 있었다. 또한 더 다양한 옵션들도 제공하고 있었다. 생각보다 활용도가 높은 패키지를 오해하고 있었구나 싶었다. 다만, recoil effect에서 비동기적으로 데이터를 initialization하는 경우 test를 어떻게 해야하는 지 아직 모르겠다.

Jest

TIL은 아직 작성하지 않았지만 그 동안 여러가지를 했다. 따라하며 배우는 리액트 테스트를 듣었던 것도 여러 일 중에 하나였다. TDD라던가 Refactoring이라던가 많이 들었지만 테스트를 어떻게 구성하는 지 몰랐기 때문이다. 심지어 CRA로 리액트 프로젝트를 만들면 App.test.tsx도 생성되는데 이게 어떤 역할을 하는 지도 몰랐다. 여튼 그래서 공부를 했는데 Testing-Library에 대해서는 따로 포스팅을 할 생각이다.

Testing-Library는 React와 UI를 테스트하는 데 특화되어 있다는 생각이 든다. 반면 Jest는 React에도 적용 가능하지만 일반적인 함수 등에도 테스트가 적용가능한 점이 다르다고 생각된다.
그래서 recoil을 적용하면서 이번에 Jest도 적용했다. default 값이 제대로 되는지 확인하기 위해 사용했다. atom의 default 값은 Object였는데 참조값을 어떻게 비교할 수 있을까, 내가 직접 그에 대한 로직도 짜야하는 것을까 생각했다. 하지만 Jest의 matcher중 toMatchObject를 사용하면 자동으로 비교해준다. Jest 짱!

리팩터링 chap2(마틴 파울러)

매번 리팩토링, 리팩토링 이야기는 들었지만 두루뭉실했다. 이 책에서는 그에 대해 보다 자세한 정의를 하고 있다.

소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

확실히 내가 리팩토링이라고 하면서 진행한 사항들은 이와는 전혀 다르구나 느꼈다. 할 때만다 겉보기 동작이 달라졌기 때문이다.😹. 이와 관련해 촌철살인의 말도 책에 실려 있다. 리팩터링과 리스트럭쳐링을 구분하자.

누군가 "리팩터링하다가 코드가 깨져서 며칠이나 고생했다"라고 한다면, 십중팔구 리팩터링한 것이 아니다.

너무나 맞는 말이라 슬프다.

아직 챕터 2까지 읽었지만 내가 코드를 짜는 방식에 적용할 점이 많아 보인다. 특히나 막 테스트를 하는 방법을 조금씩 적용하고 익혀나가는 시점이라 아주 좋은 타이밍같다.

개발할 때 목적이 '기능 추가'냐, 아니면 '리팩터링'이냐를 명확히 구분(p.81)
하나의 리팩터링을 문제없이 끝낼 때마다 커밋한다.(p.33)
조금씩 변경하고 매번 테스트하는 것은 리팩터링 절차의 핵심이다.(p.32)

특히 성능에 구속되지 말라는 식으로 말하는 점도 좋다. 물론 코드의 정리를 위해서 아예 성능적인 측면을 포기하라는 것이 아니다. 다만 리팩터링을 통해서 나를 포함한 다른 사람들이 읽기 쉽도록 코드가 정리된다면, 나중에 성능 향상을 위해서 코드를 수정할 때도 훨씬 더 편리하다는 말이 핵심인 듯 하다.

리팩터링하면 기존 코드의 설계를 얼마든지 개선 할 수 있으므로, (...) 빠른 개발이라는 숭고한 목표를 달성하려면 리팩터링이 반드시 필요하다.(p.85)

몰랐는데 CI/CD도 리팩터링과 관련된 용어였다. TDD는 물론이고.