리팩토링의 개념

리팩토링의 목적

유지 보수를 쉽게 하기 위해(코드를 이해하기 쉽고, 수정하기 쉽도록 하기 위해)
- 이해하기 쉽기 때문에 버그가 있다면 훨씬 쉽게 발견
- 코드의 중복을 제거 하여 수정하는데 쉬워짐
- 코드의 디자인을 유지하기 좋음
프로그램을 개발 생산성을 높이기 위해

3진 아웃제(3번의 중복 / 3번의 같은 행위를 한다면 리팩토링을 진행하자!)

처음에는 그냥 개발한다.
두 번째 개발에 중복 코드가 나타나도 찜찜하지만 그냥 개발한다.
세 번째 개발에 중복 코드가 발생하면 이 때가 리팩토링할 때이다.
(- 돈 로버츠, 마틴파울러의 동료)

Naming 중요성. 변수명, 클래스명, 메소드명 등 다른 사람들이 명확하게 인지할 수 있는 변수명을 사용하라!
클래스의 메소드는 클래스의 변수를 사용해야 함. 클래스의 정보를 사용하고 있지 않는다면 사용하고 있는 변수쪽으로 메소드는 움직여야 함
임시변수는 가능하면 제거하는 것이 좋음. 임시변수는 종종 쓸데없이 많은 파라미터를 만드므로 문제가 됨
임시변수를 하나의 메소드로 구현하여 리팩토링
리팩토링하는 과정에서 알고리즘적으로 성능이 더 안 좋아 질 수 있음. 하지만 어느 알고리즘 부분이 수정되어야 하는지 명확하게 보이게 되어 최적화하기 더 쉬운 형태로 변경되는 장점이 있음
다른 객체의 속성을 기반으로 한 switch문은 좋지않음. 그 부분을 함수로 추출하여 자신의 데이터를 사용하는 것으로 리팩토링해야함
메소드에서 두개의 클래스 변수를 사용하고 있다면 변화하기 쉬운쪽으로 메소드를 이동시켜 변화의 폭을 최대한 작게 해야함
기능이 한쪽으로 모여진 클래스를 추상화하여 상속관계로 표현할 수 있음
[state 패턴 / strategy패턴] 상태를 나타내는가? 알고리즘을 나타내는가에 따라 이름이 바뀔 수 있음
테스트 -> 리팩토링 -> 테스트 -> 리팩토링 -> 테스트.. 점진적인 개선작업을 수행해야함

프로그래밍을 하기 전에 미리 디자인에 대해 생각해보는 것이 비용이 많이 드는 재작업을 피하도록하는데 도움이 됨

시스템이 어떻게 돌아가는지 정확하게 알고 있다 하더라도, 추측만 하지 말고 실제로 퍼포먼스를 측정해보라. 무엇인가 배울 것이고, 십중팔구는 추측이 틀렸을 것이다.