리팩터링에 대한 진실
누군가 “리팩터링하다가 코드가 깨져서 며칠이나 고생했다”라고 한다면, 십중팔구 리팩터링한 것이 아니다.
- 코드베이스를 정리하거나 구조를 바꾸는 모든 작업을
재구성이라는 포괄적인 용어로 표현하고,
- 리팩터링은 재구성 중 특수한 한 형태로 본다.
- 즉, 코드를 정리하는 모든 작업을 모두 리팩터링이라 하는 게 아니라, 1장에서 제시한 특정한 정의에 따라 코드를 정리하는 것이 리팩토링이다.
- 리팩터링은 시간을 일정에 따로 잡아두지 않고, 대부분의 리팩터링을 다른 일을 하는 중에 처리한다.
- 보기 싫은 코드를 리팩터링하자. 그런데 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야 한다.
리팩터링 vs 성능 최적화
- 리팩터링의 목적은 코드를 이해하고 수정하기 쉽게 만드는 것이다.
- 프로그램 성능은 좋아질 수도, 나빠질 수도 있다.
- 반면 성능 최적화는 오로지 속도 개선에만 신경 쓴다.
- 그래서 목표 성능에 반드시 도달해야 한다면 코드는 다루기에 더 어렵게 바뀔 수도 있음을 각오해야 한다.
리팩터링 장점
- 소프트웨어 설계가 좋아진다.
- 리팩터링을 하면 중복 코드를 제거하고 코드량이 줄어들면 이해하고 수정하는 데 드는 노력도 줄어든다.
- 소프트웨어를 이해하기 쉬워진다.
- 내 의도를 더 명확하게 전달하고 코드가 더 잘 읽히게 도와준다.
- 이건 다른 사람을 배려하기 위함도 있지만 코드를 머리에 모두 담아두지 않는 이상 내가 다른 사람이 될 수도 있다는 사실을 명심하자.
- 버그를 쉽게 찾을 수 있다.
- 프로그래밍 속도를 높일 수 있다.
리팩터링 3의 법칙
- 처음에는 그냥 코드를 짠다.
- 비슷한 일을 두 번째로 하게 되면 일단 계속 진행한다.
- 비슷한 일을 세 번째 하게 되면 리팩터링한다.
리팩터링하지 말아야 할 때
리팩터링은 무조건 해야한다기 보단 상황에 맞게 해야 한다. 지저분한 코드를 발견해도 다음과 같은 상황이라면 굳이 수정하지 않는다.
- 외부 API 다루듯 호출해서 쓰는 코드.
- 내부 동작을 이해해야 할 시점에 리팩터링을 해야 효과를 제대로 볼 수 있다.
- 리팩터링하는 것보다 처음부터 새로 작성하는 게 쉬울 때.
💡 여기서 문제는 결정을 내리는 판단력이다. 이건 경험이 뒷받침되어야 한다.
YAGNI(애그니)
- you aren’t going to need it 필요 없을 거다의 줄임말
- 당장에 필요한 기능만으로 최대한 간결하게 만들라는 뜻이다.
- 앞으로 필요할 것 같아서 미리 구현해둔 기능 상당수가 전혀 쓰이지 않거나, 미래의 요구사항을 제대로 반영하지 못하여 오히려 수정하기 더 어려워지는 경우가 많다.
- 애그니를 받아 들인다 해서 선제적인 아키텍처에 소홀해도 된다는 건 아니지만 나중에 문제를 더 깊이 이해하게 됐을 떄 처리하는 게 더 빠를 수도 있다.
YAGNI 지켜서 야근하지 말자..
실천해볼 점
- 코드리뷰
- 페어 프로그래밍