When to refactoring?

언제 리팩토링을 해야 하는가?

리팩토링은 별도의 시간을 내서 할 것이 아니라 틈틈이 계속 해야 하는 것이다. 리팩토링 자체를 목적으로 삼는게 아니라 어떤 다른것을 위하여 리팩토링을 해야 한다.

프로그램은 두 종류의 가치를 가지고 있다. 하나는 오늘 당장을 위한 것이고, 다른 하나는 내일 위한 것이다.

• Kent Back (리팩토링 p81)

삼진 규칙

두번까지는 참는다. 세번째는 리팩토링을 할 때다.

기능을 추가할때 리팩토링 하라

1. 코드를 명확하게 하는 과정은 이해를 돕는다.

2. 형편없는 디자인은 새로운 기능을 추가하는데 시간을 보내는 것이 아니라 버그를 찾고 고치는데 시간을 소모하게 만든다. 리팩토링 없이는 새로운 기능을 추가하기 위해 소모되는 시간이 점차 늘어날 것이다. "만약 이런 식으로 디자인을 했더라면 기능 추가가 쉬웠을 텐데." 라고 생각하면 그렇게 하자.

버그를 수정해야 할때 리팩토링을 하라

1. 위와 같은 이유. 더 깊은 이해를 위한 적극적인 프로세스로 리팩토링을 사용하면 도움이 된다.

2. 버그가 나왔다는 것은 리팩토링의 신호이다. 해당 버그를 인지할수 없었을 정도로 코드가 명확하지 않았다는 뜻이다.

코드 리뷰를 할 떄 리팩토링을 하라

리팩토링은 다른 사람의 코드를 리뷰하는데 도움이 된다.

리팩토링은 코드 리뷰가 좀 더 구체적인 결과를 얻을 수 있도록 도와준다. 제안을 구현할수 있다.

이 아이디어의 극한은 XP의 페어(몹) 프로그래밍이다. 지속적인 코드 검토가 개발 프로세스에 포함된다.

reference

• 리팩토링 p78~80