💡 리팩터링이란
좋은 코드를 가늠하는 확실한 방법은 ‘얼마나 수정하기 쉬운가’이며, 좋은 코드를 위한 리팩터링은 기능은 유지한 채 유지보수가 쉽도록 코드를 재구성하는 것이다.
리팩터링 시에는 기능을 건드리지 않고 오롯이 리팩터링만 해야하며, 기능 추가를 할 때는 기능 추가만 하여야 한다.
리팩터링을 해야하는 시점
- 3의법칙, 처음에는 그냥 한다. 비슷한 일을 두번 한다고 생각되어도 찝찝하지만 그냥 한다.
하지만 비슷한 일을 세번째로 하게 될 때는 리팩터링을 실시한다. - 새로운 기능을 추가하기 직전에 리팩터링한다.
리팩터링을 하면 안되는 시점
- 지저분한 코드를 발견해도 수정이 필요하지 않으면 굳이 리팩터링하지 않는다
내부 동작을 이해해야 할 시점에 리팩터링의 효과가 제대로 나타나며, 단순히 호출하듯이 사용하는 코드나, 리팩터링 하는 것보다 새로 작성하는 것이 더 쉬울 때는 리팩터링하지 않는다. - 코드 소유권이 없거나(다른 팀에 있거나) 다른 사람과 작업을 공유하며 브랜치를 사용할 때는 리팩터링을 하지 못하거나 신중해야 한다.
⚙ 리팩터링 기법
함수 추출하기
특정 기능을 하는 함수조각을 분리하여 해당 기능을 쉽게 보여줄 수 있다.
임시변수를 질의 함수로 바꾸기
함수를 쪼개면서 임시 변수를 최대한 제거한다.
함수 선언 바꾸기
함수의 기능을 직관적으로 알 수 있도록 함수의 이름을 바꾸는 리팩토링.
처음부터 최선의 좋은 이름으로 바꾸려 하지 않아도 된다. 여러 번 보다보면 적절한 이름이 떠오를 때도 있다.
조건부 로직을 다형성(class)으로 바꾸기
특정 상황에서는 class 문법을 적절히 사용하여 조건부 로직을 다형성으로 바꿀 필요가 있다.
📝 소감 및 메모
함수들을 굳이 독립적으로 만들지 않아도 된다.
나는 중첩함수를 만들 때 어느곳에서도 사용할 수 있도록 매개변수를 전달하려는 경향이 있는데, 이미 선언된 변수를 사용하는 것이 좀 더 명확하게 보일 수 있다.
result = {} 를 사용하여 함수 별 결과값 반환
쪼갠 함수블럭을 통해 구한 값은 result = {} 와 같이 오브젝트 값으로 넣고, result.customer, result.totalAmount, total.VolumeCredits 와 같이 각각의 값으로 넣어 result를 반환한다면 진행사항을 저장할 수 있을 뿐만 아니라 결과값을 활용하기도 쉬워진다.
에러반환을 통해 의도했던 입력값 유도
인풋값 체크나 에러체크가 중요한 것은 알지만 늘 놓치게 되는 부분이다. 원하지 않는 값을 입력하면 에러를 반환하여 이후 버그가 생기지 않도록 한다.
테스트의 필요성
여느 프로그래밍 책에서도 강조하는 것이지만 리팩터링에서도 테스트를 강조한다.
테스트의 필요성이 가장 와닿았던 부분은 다른 사람이 작성한 코드를 리팩터링할 때 테스트코드가 없다면 리팩터링하기가 매우 힘들어진다는 것이다.
당장 내가 작성한 코드도 괜히 건드렸다가 잘못될까봐 못건드리는 상황이 많은데, 다른 사람이 작성한 코드는 더 심하다. 이때문에 리팩터링하기 꺼려지는 프로젝트들이 꽤 있는데, 테스팅코드가 있다면 기꺼이 리팩터링을 진행하지 않았을까 싶다.
