Refactoring is something I do every hour I program. I have noticed a number of ways it fits into my workflow.

-> 리팩토링은 내가 프로그램을 작성하는데 매 시간마다 하는 일이다. 나는 그것이 내 작업 흐름에 적합하게 맞춰지는 방법을 몇 가지 발견했다.

룰 3가지

• 처음 어떤 일을 할 땐 그냥 한다.
• 두 번째로 비슷한 일을 할 땐 중복된 것을 보고 움찔하지만 또 중복된 일을 한다.
• 세 번째로 중복되는 부분을 발견하면 리팩토링을 해서 코드를 개선한다.

Preparatory Refactoring—Making It Easier to Add a Feature

리팩토링 준비 - 기능 추가를 쉽게 만들기

• 해석

→ “나는 100마일 동쪽으로 가고 싶은데, 그냥 숲속을 헤치고 가는 대신, 20마일 북쪽으로 가서 고속도로를 타고 100마일을 동쪽으로 가면 내가 직진했을 때보다 세 배 빠르게 갈 수 있다는 말이다. 사람들이 그냥 직진하라고 재촉할 때, 가끔은 ‘잠깐, 지도를 확인하고 가장 빠른 길을 찾아야겠다.’고 말해야 한다. 준비 작업으로서의 리팩토링이 바로 나를 그렇게 해준다.” — *Jessica Kerr*

<aside>

• 리팩토링을 하기에 가장 좋은 시간은 코드 베이스에 기능을 추가해야할 시점 전이다.
• 구조화된 코드여야 새로운 기능을 추가하기 훨씬 수월할 것이다.
• 리팩토링이 없다면 재사용성이 떨어지고 같은 기능을 하는 코드도 중복 코드를 사용할 것이다.
• 리팩토링 시에는 함수에 파라미터화(310)를 사용한다. → 필요한 파라미터로 함수를 호출 </aside>

Comprehension Refactoring: Making Code Easier to Understand

이해력 리팩토링: 코드를 더 쉽게 이해할 수 있게 만들기