Skip to content

Latest commit

 

History

History
52 lines (29 loc) · 3.85 KB

File metadata and controls

52 lines (29 loc) · 3.85 KB

CHAPTER 2

리팩터링

리팩터링 : 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
리팩터링(하다) : 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러 가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다

리팩터링 중에는 적용하는 리팩터링 기법은 수십 가지

두 개의 모자

소프트웨어 개발 시 목적이 기능 추가냐, 아니면 리팩터링이냐를 명확히 구분해 작업. 기능을 추가할 때는 기존 코드는 절대 건드리지 않고 새 기능을 추가하기만 한다. 진척도는 테스트를 추가해서 통과하는지 확인하는 방식으로 측정한다. 반면 리팩터링할 때는 '리팩터링' 모자를 쓴 다음 기능 추가는 절대 하지 않기로 다짐한 뒤 오로지 코드 재구성에만 전념한다.

리팩터링의 이점

  1. 리팩터링하면 코드의 설계가 좋아진다.
    같은 일을 하더라도 설계가 나쁘면 코드가 길어지기 쉽상이다. 사실상 같은 일을 하는 코드가 여러 곳에 나타날 수 있기 때문이다. 그래서 중복 코드 제거는 설계 개선 작업의 중요한 한 축을 차지한다. 코드량을 줄인다고 시스템이 빨라지는 것은 아니다. 프로그램의 용량이 속도에 영향을 주는 경우는 별로없다. 하지만 코드량이 줄면 수정하는데 드는 노력은 크게 달라진다.
  2. 리팩터링하면 소프트웨어를 이해하기 쉬워진다.
    프로그래밍에서는 사람이 가장 중요하지만 소홀하기 쉽다. 코드를 컴파일하는 데 시간이 살짝 더 걸린다고 누가 뭐라 하겠는가? 하지만 다른 프로그래머가 내 코드를 제대로 이해했다면 한 시간에 끝낼 수정을 일주일이나 걸린다면 사정이 달라진다. 사실 그 다른 사람이 나 자신일 때가 많다.
  3. 리팩터링하면 버그를 쉽게 찾을 수 있다.
    켄트백: 난 뛰어난 프로그래머가 아니에요. 단지 뛰어난 습관을 지닌 괜찮은 프로그래머일 뿐이에요.
  4. 리팩터링하면 프로그래밍 속도를 높일 수 있다.
    내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다. 모듈화가 잘 되어 있으면 전체 코드베이스 중 작은 일부만 이해하면 된다.

언제 리팩터링해야 할까?

  1. 처음에는 그냥 한다.
  2. 비슷한 일을 두 번쨰로 하게 되면(중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다.
  3. 비슷한 일을 세 번째 하게 되면 리팩터링한다.

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

현재 코드에서 구조를 살짝 바꾸면 다른 작업을 하기가 훨씬 쉬워질 만한 부분을 찾는다. 요구사항을 거의 만족하지만 리터럴 값 몇 개가 방해되는 함수가 있을 수 있다. 함수를 복제해서 해당 값만 수정하거나, 중복 코드가 신경 쓰이면, 함수 매개변수화하기를 적용한다.

비유하면 지금 위치에서 동쪽으로 100km를 이동하려는데 그 사이를 숲이 가로막고 있다면, 좀 둘러가더라도 20km 북쪽에 있는 고속도로를 타는 편이 세 배나 빠를 수 있다. 다들 "직진!"을 외치더라도, 때로는 "잠깐, 지도를 보고 가장 빠른 경로를 찾아보자"고 말할 줄 알아야 한다. 준비를 위한 리팩터링이 바로 이런 역할을 한다.

버그를 잡을 떄도 마찬가지다. 오류를 일으키는 코드가 세 곳에 복제되어 퍼져 있다면, 우선 한 곳으로 합치는 편이 작업하기에 훨씬 편하다.

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