들어가면서
팀 단위의 과제를 수행하면서, 한 명의 잘한 코드에 대해서 부족하다고 생각하는 부분을 리팩토링해보자라는 의견이 나왔고, 아래와 같이 추가로 포함되었으면 하는 사항을 정리해보았다.
- 기존 구현 방식에서 Context API 활용하여 전환
- 추천 검색어 결과값이 8개를 초과할 경우 상위 8개까지 저장 및 노출
- 특정 키를 입력했을 경우에 대한 기능 추가
- 기능 바깥 영역 클릭 시 드롭다운 비활성화
- 컴포넌트를 더 작은 단위로 추상화하기
- proxy로 CORS 우회
이렇게 보완해야할 점을 토론한 후에, 혼자 수정하는 과정에서 ‘어디까지 코드를 고쳐야하는거지? 코드 구조를 바꿔도 되는건가?’, ‘이 부분이 추가되는 거면, 내부 코드를 뜯어고쳐야하는데 괜찮은건가?’하는 고민을 많이하게 되었고, 내가 ‘리팩토링(Refactoring)’이라는 개념을 잘 이해하지 못하고 있다는 것을 느껴서 정리해보기로 했다.
리팩토링?
💡 리팩토링(Refactoring)은 소프트웨어 공학에서 ‘결과의 변경없이 코드의 구조를 재조정함’을 뜻하는 말이다. 가독성을 높이고 유지보수를 편하게 하기 위해 행하는 것이다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다.
리팩토링의 개념을 보았을 때 가장 눈에 띄는 부분은 ‘결과의 변경없이’라는 점이었다. 리팩토링은 기능적인 향상이 주요한 목적이 아니기 때문에 리팩토링으로 인해서 결과가 변경되거나, 새로운 요구사항을 통해 새로운 기능을 추가하는 것은 리팩토링으로 보지 않는 것 같다.
그렇다면 앞서 우리 팀에서 설정한 요구사항들을 보았을 때,
- Context API를 활용하여 불필요한 Props Drilling 개선
- 컴포넌트 추상화
정도가 실제 리팩토링의 목적에 부합하는 사항들인 것 같다. 나머지는 진짜 새로운 요구사항을 만들어 낸 것이었다.
왜 리팩토링을 해야하는가?
리팩토링의 목적은 가독성과 유지보수성의 향상이다.
리팩토링을 거쳐 읽기 쉽고, 수정하기 쉬운 코드를 만들어 놓으면 이후 버그가 발견했을 때도 비교적 쉽게 수정할 수 있고, 그 과정에서도 잠재적인 버그를 발견할 수 도 있다. 결국 일을 잘하기 위해서 리팩토링을 하는 것이다.
언제 리팩토링을 해야하는가?
그렇다면 언제 리팩토링해야할까. 보편적으로 아래와 같은 상황에서 리팩토링을 고려한다고 한다.
- 같은 동작을 3번 이상하게 된다면 리팩토링을 고려하자. -The Rules of Three (삼진 규칙)
- 기능을 추가할 때 리팩토링을 고려하자.
- 버그를 수정할 때 리팩토링을 고려하자.
- 코드 리뷰를 할때 리팩토링을 고려하자.
리팩토링과 클린코드
클린코드는 가독성을 높이기 위한 방법을 말하고, 리팩토링은 가독성 뿐만 아니라 유지보수성까지 고려하여 코드를 수정하는 작업을 말한다.
두 가지는 어느 한 쪽이 더 큰 개념이라기 보다 두 가지의 적용 시점이 다른 것 같다고 생각한다. 클린코드는 우리가 설계하는 시점부터 계속해서 고려해야하는 사항들이고, 리팩토링은 일단 기능이 완성된 이후부터 클린코드와 함께 적용될 수 있는 개념이지 않을까 생각한다.
이 두가지를 비교한 글을 여럿 볼 수 있어서 나도 내 생각을 적어봤다. ☺️
Reference
https://ko.wikipedia.org/wiki
https://velog.io/@rlrhs11/Code-Refactoring
