[리팩터링 2판] 챕터2 - 리팩터링의 원칙

2.1 리팩터링의 정의

 

리팩터링:

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

 

챕터 2의 강조점은 리팩터링의 정의 그 자체였다.

 

책에서는 이 점을 계속해서 반복한다.

리팩터링은 기능을 추가하거나 버그를 수정하거나 성능을 향상시키기 위한 목적이 아니다.

그저 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법이라는 것이다.

 

 

1. 리팩터링 하는 동안에는 코드가 항상 정상 작동해야 한다

-> 구조만 변경하는 것이기 때문에

 

2. 리팩터링 과정에서 발견된 버그는 리팩터링 후에도 그대로 남아 있어야 한다

-> 구조만 변경하는 것이기 때문에

 

3. 리팩터링 할 때에는 테스트를 새로 만들지 않는다. 물론 부득이하게 인터페이스를 변경해야할 때에는 테스트를 수정한다

-> 구조만 변경하는 것이기 때문에

 

 

2.3 리팩터링하는 이유

소프트웨어 설계가 좋아진다

리팩터링을 통해 반복되는 중복 코드를 제거하면 모든 코드가 언제나 고유한 일을 수행함을 보장할 수 있다.

 

소프트웨어를 이해하기 쉬워진다

리팩터링은 코드가 더 잘 읽히게 도와준다. 따라서 개발자가 어떤 의도를 가지고 코드를 작성했는지 그 목적을 더 잘 드러나게 할 수 있다.

 

버그를 쉽게 찾을 수 있다

코드를 이해하기 쉽다는 말은 버그를 찾기 쉽다는 말이기도 하다. 리팩터링하면 코드가 하는 일을 깊이 파악할 수 있어서 깨달은 것을 코드에 금방 반영할 수 있다.

 

프로그래밍 속도를 높일 수 있다

반대가 아닌가라고 생각할 수 있다.

하지만 시간이 지나면서 기능이 지속적으로 추가되면 내부 설계가 잘 된 소프트웨어와 그렇지 않은 소프트웨어의 기능 추가 속도는 확연히 차이난다.

 

내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다.

코드가 명확하면 버그를 만들 가능성이 줄고, 디버깅하기가 훨씬 쉽다.

이렇듯 내부 품질이 뛰어난 코드베이스는 새 기능 구축을 돕는 견고한 토대가 된다.

 

 

 

2.4 언제 리팩터링 해야 할까?

 

3의 법칙

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

 

 

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

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

코드를 살펴보면서 코드를 살짝 바꾸면 다른 작업을 하기가 훨씬 쉬워질 부분을 찾는다

 

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

코드를 파악할 때마다 그 코드의 의도가 더 명확하게 드러나도록 리팩터링할 여지는 없는지 찾아본다

머리로 이해한 것을 코드에 옮겨 담을 수 있도록 한다.

 

쓰레기 줍기 리팩터링

쓰레기가 나뒹굴게 방치해서 나중에 일을 방해하도록 내버려두는 것은 좋지 않다.

간단히 수정할 수 있는 것은 즉시 고치고, 시간이 좀 걸리는 일은 하던 일을 끝내고 나서 처리한다.

리팩터링은 각각의 작은 단계가 코드를 깨뜨리지 않는다

 

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

보기 싫은 코드를 발견하면 리팩터링하자. 그런데 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야 한다.

무언가 수정하려고 할 때는 먼저 수정하기 쉽게 정돈하고 그런 다음 쉽게 수정하자

리팩터링 작업은 대부분 드러나지 않게, 기회가 될 때마다 해야 한다.

 

오래 걸리는 리팩터링

팀 전체가 참여해서 많은 시간을 할애하는 대규모 리팩터링도 있다. 그보다는 주어진 문제를 몇 주에 걸쳐 조금씩 해결해나가는 편이 효과적일 때가 많다. 누구든지 리팩터링해야할 코드와 관련한 작업을 하게 될 때마다 원하는 방향으로 조금씩 개선하는 식이다.

 

코드 리뷰에 리팩터링 활용하기 

리팩터링은 다른 이의 코드를 리뷰하는 데도 도움된다. 코드 리뷰의 결과를 더 구체적으로 도출하는데에도 도움이 된다.

 

 

리팩터링하지 말아야 할 때

굳이 수정할 필요가 없다면 리팩터링 하지 않는다.

-> 내부 동작을 이해해야 할 시점에 리팩터링을 해야 효과를 제대로 볼 수 있다.

 

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

 

 

 

2.5 리팩터링 시 고려할 문제

 

리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것이다.

 

1. 리팩터링을 해서 새 기능을 구현하기 편해질 것 같다면 리팩터링을 먼저 한다

 

2. 리팩터링은 개발 기간을 단축하고, 기능 추가 시간을 줄이고, 버그 수정 시간을 줄이기 위한 경제적인 이유로 하는 것이다.

클린 코드에 지나치게 집착하지 말자

물론 좋은 설계는 지향해야 하지만 클린 코드가 리팩터링의 궁극적인 목적이 되어서는 안된다

 

3. 테스팅

리팩터링하기 위해서는 대부분의 경우 자가 테스트 코드를 마련해야 한다.

자가 테스트 코드는 리팩터링을 할 수 있게 해줄 뿐만 아니라, 새 기능 추가도 훨씬 안전하게 진행할 수 있도록 도와준다.

 

4. 레거시 코드

레거시 시스템을 파악할 때 리팩터링이 굉장히 도움이 된다.

대규모 레거시 시스템을 테스트 코드 없이 명료하게 리팩터링하기는 어렵다

따라서 테스트 보강을 해야 한다.

프로그램에서 테스트를 추가할 틈새를 찾아서 시스템을 테스트해야 한다.

 

 

2.6 리팩터링, 아키텍처, 애그니(YAGNI)

리팩터링이 아키텍처에 미치는 실질적인 효과는 요구사항 변화에 자연스럽게 대응하도록 코드베이스를 잘 설계해준다는 것이다.

현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축하고, 진행하면서 아키텍처도 그에 맞게 리팩터링해서 바꾼다.

 

 

 

2.8 리팩터링과 성능

리팩터링하면 소프트웨어가 느려질 수도 있는 건 사실이다. 하지만 동시에 성능을 튜닝하기는 쉬워진다.

튜닝하기 쉽게 만들고 나서 원하는 속도가 나게끔 튜닝하는 것이다.

 

리팩터링을 잘 해두면 최적화에 2가지 면에서 도움이 된다

1. 성능 튜닝에 투입할 시간을 벌 수 있다.

-> 기능 추가가 빨리 끝나서 성능에 집중할 시간을 더 벌 수 있다.

 

2. 성능을 더 세밀하게 분석할 수 있다.

프로파일러가 지적해주는 코드의 범위가 더 좁아질 것이고, 튜닝하기 쉬워진다. 또한 코드가 깔끔하면 개선안들이 더 잘 떠오를 것이다.

 

= 리팩터링은 성능 좋은 소프트웨어를 만드는 데에 기여한다.