📕 리팩터링 2판 리뷰: 2장, 3장

📕 리팩터링 2판 : 코드 구조를 체계적으로 개선하여 효율적인 리팩터링 구현하기 리뷰

 

리팩터링 2판의 2장과 3장을 읽고 왔습니다. 최근에 면접이 잡히고, 면접 공부를 병행하느라 하루에 작은챕터 2장씩만 읽고 있네요.. 합격한다면 읽는 속도 좀 팍팍 내보고 싶습니다. 🥲

리팩터링 2판의 2장과 3장의 리뷰를 시작해보겠습니다. 

---

⭐️ 2장: 리팩터링 원칙

2장에서는 리팩터링의 정의, 리팩터링의 유래 등과 함께 리팩터링 전반에 적용되는 원칙들에 대해 알아봅니다. 

 

⭐️ 3장: 코드에서 나는 악취

3장에서는 리팩터링을 제때 적용하는 법을 알기 위해, 코드에서 나는 냄새(악취)를 감지하는 법에 대해 알아봅니다.

---

 

🤔 느낀 점

2장(리팩터링 원칙)에서는 리팩터링이 얼마나 좋은건지, 리팩터링의 효험(?)을 설명해주기도 하지만 무작정 리팩터링하는 것이 좋은 것은 아님을 알게되었습니다. 특히 2-4장(언제 리팩터링해야 할까?)에서 리팩터링하지 말아야할 때를 다루는데, 지저분한 코드를 발견해도 굳이 필요가 없다면 리팩터링하지 않는다는 점(외부 API 다루듯 호출해서 쓰는 코드라면 지저분해도 그냥 둠), 처음부터 새로 작성하는게 쉬울 때는 리팩터링하지 않는다는 점(이를 결정하려면 뛰어난 판단력과 경험이 뒷받침돼야 함)이 인상적이었습니다. 사실 당연하지만 리팩터링이 마냥 좋다고 무작정 하기보다는 비용을 철저히 계산해서 리팩터링하는 것이 더 효율적일 때만 해야 한다는 것을 알게 되었습니다. 

3장(코드에서 나는 악취)에서는 리팩터링을 제때 적용하는 법을 알게 되었는데, 이전에 해왔던 프로젝트들을 떠올리면서 어느 부분의 코드에서 악취가 나고 있나 생각을 해보았습니다. 제가 유독 찔림을 느꼈던 구간은 3-5장(전역 데이터)인데요, 코드스테이츠 4주 프로젝트를 진행하면서 한창 Redux-toolkit의 편리함에 빠져 굳이 전역 데이터로 안써도 됐었던 데이터들을 전역 데이터로 만들어 사용했던 적이 있습니다. props로 넘기는게 더 귀찮았던 모양입니다.. 😂

 

전역 데이터는 코드베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다는 게 문제다. 그래서 마치 '유령 같은 원격작용'처럼, 버그는 끊임없이 발생하는데 그 원인이 되는 코드를 찾아내기가 굉장히 어렵다.

 

이를 방지하기 위해서는 변수 캡슐화하기라는 리팩터링을 적용할 수 있다고 합니다. 리팩터링 기법을 배우는 파트에서 배우게 되겠지만, 그 전에 더 중요한 것은 애초에 전역변수로 안써도 되는 것들이 있다면 안쓰는게 좋지 않을까 하는 생각입니다. 이외에도 프로젝트를 리팩터링할 때 3장의 내용을 참고하여 어느 부분을 리팩터링하면 될까 파악하고 가면 좋겠다는 생각을 했습니다.

다음 챕터는 제가 제일 기대하던 4장, 테스트 구축하기입니다. 글쓴이가 매우 강조한 파트인만큼 제대로 이해하고 써먹을 수 있게끔 해봐야겠습니다.

긴 글 읽어주셔서 감사합니다.