리팩터링 2판 2장 - 리팩터링 원칙 1탄

리팩터링: 소프트웨어의 겉보기 동작은 그대로 유지한 채 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

예시 코드가 없는 텍스트이기 때문에 기억에 남는 글만 기록하겠다.

 

두개의모자

목적이 기능추가 또는 리팩터링이냐를 명확히 구분해 작업을 한다.

 

리팩터링을 하면 버그를 쉽게 찾을 수 있다.

뛰어난 프로그래머는 아니지만 좋은 습관을 가진 프로그래머가 되자!

 

언제 리팩터링을 해야할까 (3의 법칙)

1. 처음에는 그냥 한다.

2. 비슷한 일을 두 번째로 하게 되면(중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다.

3. 비슷한 일을 세 번째 하게 되면 리팩터링 한다.

 

준비를 위한: 리팩터링

리팩터링하기 가장 좋은 시점은 코드베이스에 기능을 새로 추가하기 직전이다. 함수 매개변수화하기 를 적용해서 중복 코드를 없앤다.

 

이해를 위한: 리팩터링

코드의 의도가 명확하게 드러나도록 한다. 조건부 로직의 구조가 이상하지 않은지 함수 이름을 잘못 정해서 실제로하는 일을 파악하는 데 오래 걸리지 않는지 등등

 

쓰레기 줍기 리팩터링

로직이 쓸데없이 복잡하거나 똑같은 함수가 여러개일 경우 간단히 수정할 수 있는 일은 끝내고 시간이 좀 걸리는 일은 짧은 메모만 남긴 다음 하던 일을 끝내고 나서 처리한다.

 

계획된 리팩터링과 수시로 하는 리팩터링

리팩터링 일젖ㅇ을 따로 잡아두지 않고, 기능을 추가하거나 버그를 잡는 동안 리팩터링도 함께 한다. 보기 싫은 코드를 발견하면 리팩터링을 하자. 그런데 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야한다. 

 

리팩터링을 하지 말아야 할때

지저분한 코드를 발견해도 굳이 수정할 필요가 없다면 리팩터링하지 않는다. 내부 동작을 이해해야 할 시점에 리팩터링 효과를 볼 수 있다.

리팩터링 하는 것보다 처음부터 새로 작성하는게 쉬울 때도 리팩터링하지 않는다.