2장. 리팩터링 원칙

(이 책에서 정의하는) 리팩터링의 정의

• 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
• 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하는 것
• 동작을 보존하는 작은 단계들을 거쳐 코드를 수정하고, 이러한 단계들을 순차적으로 연결하여 큰 변화를 만들어내는 것
• 개별 리팩터링은 그 자체로 아주 작을 수도 있고, 작은 단계 여러 개가 합쳐진 모습일 수도 있다.
• 따라서 리팩터링하는 동안에는 코드가 항상 정상 동작하기 때문에 전체 작업이 끝나지 않았더라도 언제든 멈출 수 있다.
• 소프트웨어 개발 시에 한 가지 목적에만 집중하기
• 리팩터링할 때 기능 추가는 하지 않는다.

 

 

리팩터링하는 이유

1. 리팩터링하면 소프트웨어 설계가 좋아진다 : 리팩터링하지 않고, 아키텍처를 충분히 이해하지 못한 채 단기 목표만을 위해 코드를 수정하다 보면 기반 구조가 무너지기 쉽다.
2. 리팩터링하면 소프트웨어를 이해하기 쉬워진다.
3. 리팩터링하면 버그를 쉽게 찾을 수 있다.
4. 리팩터링하면 프로그래밍 속도를 높일 수 있다.

 

언제할까?

• 비슷한 일을 세 번째 하게 되면 리팩터링한다.
• 분류
  • 1. 준비를 위한 리팩터링 : 기능을 쉽게 추가할 수 있도록 만들기
    2. 이해를 위한 리팩터링 : 코드를 이해하기 쉽게 만들기
    3. 쓰레기 줍기 리팩터링
    4. 계획된 리팩터링과 수시로 하는 리팩터링
    5. 오래 걸리는 리팩터링
    6. 코드 리뷰에 리팩터링 활용
    7. 관리자에게는 뭐라 말해야해
    8. 리팩터링하지 말아야 할 때도 있다.

 

 

 

리팩터링과 성능

• 느려질 수도 있음 (사실임)
• 근데 그와 동시에 성능을 튜닝하는 것이 쉬워짐 (그렇다고 함)
• 성능에 대한 흥미로운 사실은 대부분의 프로그램은 전체 코드의 극히 일부에서 대부분의 시간을 소비한다는 것
• 그래서 전체 코드를 고르게 최적화한다면 그 중 90%는 효과가 거의 없기 때문에 시간 낭비인 셈이다.
• 이는 통계적인 사실이며, 이를 바탕으로 의도적으로 성능 최적화에 돌입 전까지는 성능 신경쓰지 않고, 코드를 다루기 쉽게 만드는데 집중
• 먼저 프로파일러로 프로그램을 분석하여 시간과 공간을 많이 잡아먹는 지점을 알아낸다.

 

 

[마틴 파울러 - 리팩터링] 발췌