리팩토링의 몇가지 더 넓은 원칙에 대해 이야기할 것이다.

refactoring은 실무자들에 의해 느슨하게 사용된다.

refactoring이라는 용어를 좀 더 정확하게 정확한 형태로 사용하는 것이 유용하다고 생각한다.

refactoring이라는 용어는 명사나 동사로 사용될 수 있다.

refactoring의 정의

<aside>

• refactoring 명사의 정의

  : 식별할 수 있는 행동의 변화 없이 소프트웨어의 내부 구조를 이해하기 쉽고 변경하기 쉽게 만드는 과정이다.

  : 이 정의는 앞의 예제에서 언급한 **Extract Function (106), Replace Conditional with Polymorphism (272)**와 같은 정의된 리팩토링 기법과 일치한다.

  ** **Extract Function (106): 함수 추출**

  ** Replace Conditional with Polymorphism (272): 다형성을 조건문으로 대체

• refactoring 동사의 정의

  : 소프트웨어의 식별할 수 있는 행동을 변경하지 않으면서 일련의 리팩토링을 적용하여 소프트웨어를 재구성하는 것이다.

  : 몇시간 동안 리팩토링을 하면서, 그 동안 몇십 개의 개별적인 리팩토링을 적용할 수 있다.

</aside>

refactoring의 접근법

<aside>

수 년간, 산업의 많은 사람들은 리팩토링이라는 용어를 모든 종류의 코드 정리를 의미하는데 사용해왔다.

하지만 위 정의는 코드 정리를 위한 특정한 접근법을 가리킨다.

리팩토링이란 작은 동작을 유지하는 단계를 적용하는 것에 관한 것이다.

그리고 이러한 동작을 유지하는 단계들을 연속적으로 연결함으로써 큰 변화를 이루는 것이다.

각각의 리팩토링은 그것 자체로 꽤 작은 작업이거나, 작은 단계들의 조합이다.

결과적으로 리팩토링을 할 때 코드가 깨진 상태로 머무는 시간이 많지 않게 된다. 이는 작업이 끝나지 않았더라도 언제든 멈출 수 있게 해준다.

</aside>

→ 작은 변화를 축적해 큰 변화를 이루는 과정이 리팩토링이다.

만약 누군가가 리팩토링하는 동안 코드가 며칠 동안 깨져 있었다고 말한다면, 그들은 리팩토링을 하고 있지 않은게 거의 확실하다.

• 46p 해석

리팩토링

<aside>

• 코드 베이스를 재구성하거나 정리하는 작업의 특정한 종류로, 코드가 더 쉽게 이해되고 수정할 수 있도록 만드는 것이다.
• 작은 단계를 밟아가며 진행, 그래야 작은 단계들이 잘 결합되어 빠르게 진행할 수 있고 디버깅에 시간낭비를 안한다.
• 리팩토링 하기 전과 후의 동작은 같아야 한다.
• 리팩토링 중 발견된 버그는 리팩토링 후에도 존재해야하며, 리팩토링 중 잠재적인 버그는 수정할 수 있다.
• 리팩토링은 코드를 더 쉽게 이해하고 변경하기 쉽도록 만드는 것이 목적이기 때문에 속도에 신경을 쓰지 않는다.
• 성능 최적화는 속도 향상에만 집중하며, 더 어려운 코드가 되어도 성능 향상에 필요하면 감수한다. </aside>