[refactoring] 1. 리팩터링 원칙

리팩터링이란?

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

 

- 리팩터링 하기 전과 후의 코드가 똑같이 동작해야 한다.

 

- 리팩터링은 성능 최적화와 비슷하다. 코드를 변경하지만, 전반적인 기능은 그대로 유지한다.

 

소프트웨어 개발의 목적은 두 가지로 '기능 추가'인지, '리팩터링'인지를 구분해서 작업하는 게 좋다.

'기능 추가', '리팩터링' 두 작업을 번갈아가면서 할 수는 있어도 동시에 안 하는 게 좋다.

 

리팩터링을 하는 이유?

- 소프트웨어 설계가 좋아진다. 리팩터링을 하지 않으면 내부 설계(아키텍처)가 썩기 쉽다.

- 소프트웨어를 이해하기 쉬워진다. 몇 달이 지난 누군가 내 코드를 수정하고자 읽을 때를 위함일 수도 있다.

어떻게 보면 나 자신뿐만 아니라 다른 사람을 위한 '소통의 수단' 같다. (사실 나 자신과의 소통 일수도)

- 버그를 쉽게 찾을 수 있다. 사소할 수도 있겠지만, 코드의 양이 많아진다면 더욱더 효과를 볼 수 있을 것이다.

- 프로그래밍 속동을 높일 수 있다. 즉, 코드 개발 속도가 더 빨리질 수도 있다. 리팩터링 자체에 시간을 많이 쓸 수도 있겠지만, 장기적으로 본다면 결코 그렇지 않을 것이다.

 

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

1. 처음에는 그냥 한다.

2. 비슷한 일을 두 번째로 하게 되면 (중복되면) 일단 계속한다.

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

 

 

준비를 위한 리팩터링 : 기능을 쉽게 추가하게 만들기

- 리팩터링 하기 가장 좋은 시점은 코드 베이스에 기능을 새로 추가하기 직전이다.

 

이해를 위한 리팩터링 :  코드를 이해하기 쉽게 만들기

- 코드를 수정하려면 먼저 그 코드가 하는 일을 파악해야 한다. 코드의 의도가 더 명확하게 드러나도록 리팩터링 할 여지를 를 찾는다.

 

쓰레기 줍기 리팩터링

당장 더 급한 일이 있을 때, 리팩터링 할 곳이 보이면 간단한 거면 즉시 고치고, 시간이 오래 걸릴 것 같으면 간단하게 메모해 놓고, 나중에 돌아와서 리팩터링 하자

 

계획된 리팩터링, 수시로 리팩터링

프로그램을 개발할 때 리팩터링 계획을 따로 잡을 수도 있겠지만, 개발의 연장선으로 수시로 해주는 게 좋다. 버그를 고치면서도 할 수 있고, 보기 싫은 코드를 고칠 수도 있다. 그리고 잘 작성된 코드라도 수많은 리팩터링을 거쳐야 한다. 상황에 따라 리팩터링여부도 살짝씩 다르다.

"무언가 수정하려 할 때는 먼저 수정하기 쉽게 정돈하고, 그런 다음에 쉽게 수정하자." -켄트 백

 

 

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

- 처음부터 새로 작성하는 게 쉽다면 리팩터링 하지 않는다.

- 외부 API를 호출해서 쓰는 코드라면, 내부 동작을 이해해야 할 시점에 리팩터링 해야 효과를 제대로 볼 수 있다.