기존에 코드가 있다. 이 코드는 하나의 함수로 이루어진 코드이며 수정이 일어나면 해당 함수를 수정해야만 하는 구조다.
이 함수를 수정했을 때 테스트해야 하는 영역이 세 곳이 있다고 할 때 요청사항으로 인해 수정이 빈번하게 일어난다면 기존 함수와 변경된 부분을 수정하고 테스트해야 하는 입장에서는 죽을 맛일 것이다.
만약 요구사항이 1~2개씩 들어오는 상황이라는 이상적인 경우라면 시간이 들더라도 할 수 있겠지만 실제로 요구사항은 1~2개가 아닌 n개가 들어온다. 이 n개의 요구사항을 다 테스트하고 수정한다면 소모되는 시간은 기하급수적으로 늘어날 것이다. 리팩터링이 필요한 이유가 바로 앞에 말한 상황이 있기 때문이다.
잘 작동하고 변경할 일이 없는 코드도 언젠가는 변경할 일이 생길 수 있기 때문에 코드를 읽기 쉽고 이해하기 쉽게 로직을 짜야한다.
리팩터링의 첫 단계
리팩터링의 첫 단계는 항상 리팩터링을 할 코드 영역을 꼼꼼하게 검사해줄 테스트 코드를 마련하는 것이다.
리팩 터링 기법들이 버그 발생 여지를 최소화하도록 구성됐다고는 하나 실제 작업은 사람이 수행하기 때문에 버그가 일어날 수 있다. 이는 프로그램이 클 수 록 빈번하게 일어난다.
리팩터링 하기 전에 제대로 된 테스트부터 마련한다.
테스트는 반드시 자가 진단하도록 만든다.
리팩터링은 프로그램 수정을 작은 단계로 나눠 진행한다. 그래야 중간에 실수하더라도 버그를 쉽게 찾을 수 있다.
코드에서 함수로 추출할만한 부분이 있다면 그 부분을 추출해 하나의 함수로 만들어 복잡도를 낮춰준다.
또한 해당 함수가 어떤 기능을 하는지 명확하게 알아볼 수 있도록 이름을 정해야 한다.
ex) 값이 같은지 확인하는 함수 A.equal("TEST"); 누가 봐도 같은지 확인하는 함수
반환하는 변수는 result로 지정해 파악하기 쉽게 할 수 있다.
매개변수로 play, play.b를 보낸다면 불필요한 play.b를 제거한다. → play.b는 play안에 있기 때문에 로컬 범위에 존재하는 이름이 늘어나서 추출 작업이 복잡해진다.
반복문 쪼개기 → 서로 다른 역할을 하는 변수가 하나의 반복문에 있을 때는 반복문을 나누어 명확하게 할 수도 있다.
반복문 하나를 2개로 나누기 때문에 그에 따른 성능 저하가 일어난다는 걱정을 할 수 있지만 실제로 그 영향은 미미할 때가 많다
리팩터링 때문에 성능이 떨어진다면, 하던 리팩터링을 마무리하고 나서 성능을 개선하자.
-> 성능이 떨어질 수 있지만 잘 다듬어진 코드가 성능을 개선하기 쉽기 때문에 각자의 판단으로 리팩터링을 진행하라
리팩터링 4가지
반복문 쪼개기 - 역할이 다른 변수를 분리한다
문장 슬라이드 하기 - 변수 초기화 문장을 for문 바로 앞으로 옮긴다.
함수 추출하기 - 추출할 수 있는 부분이 있다면 하나의 함수로 만든다
변수 인라인 하기 - 코드를 명확하게 볼 수 있다.
조건부 로직을 다형성으로 바꾸기(팩토리 패턴 익히기) - 인터페이스를 만들어 해당 인터페이스를 상속받아 조건별로 객체를 다르게 생성하는 패턴
좋은 코드를 가늠하는 확실한 방법은 '얼마나 수정하기 쉬운가'다.
"리팩터링을 진행하며 항상 생각해야 하는 것은 컴퓨터가 이해하기 쉽게 만드는 것이 아닌 사람이 이해하기 쉽게 만드는 것이다."
