리팩토링 - 시작하기2

<완벽한 설계 vs 리팩토링>

- 리팩토링을 통해 개발자는 수정할 때 따르는 위험성에 다른 각도로 대처할 수 있다. 개발자는 여전히 잠재적 수정 가능성을 생각하고 유연한 솔루션을 고려한다. 하지만 무작정 유연한 솔루션을 구현할 것이 아니라 먼저 

"단순한 솔루션을 구현해 놓고 그걸 나중에 유연한 솔루션으로 리팩토링하려면 얼만큼 수고가 들까?" 

하고 스스로 고민해보자. 그래서 만약 웬만한 경우처럼 어려움이 없다고 판단되면 고민할 것 없이 단순한 솔루션을 구현하면 된다.

- 리팩토링을 실시하면 유연성을 낮추지 않고도 더 간결한 설계가 가능해진다. 그래서 설계 과정이 쉬워지고 스트레스도 줄어든다. 리팩토링을 쉽게 할수 있는 감각을 넓히게 되면 그땐 유연한 솔루션은 떠오르지도 않는다. 때가 되면 어련히 리팩토링하게 되리란 확신이 있기 때문이다. 잘 돌아갈 정도로만 제일 단순한 솔루션을 구축하자. 유연하고 복잡한 설계가 필요한 상황은 거의 없으니 말이다.

<리팩토링과 성능>

- 성능 향상을 위한 코드 최적화가 먼저인가 리팩토링이 먼저인가

- 대부분의 경우 성능 향상을 위한 노력은 시간낭비와 저효과로 이어진다.

- 리팩토링을 하면 생산성이 높아지고 성능 향상을 위한 튜닝을 하기 쉬운 코드로 이어진다.

- 즉 코드가 더 깔끔하니까 개발자가 성능을 위한 후보 튜닝에 대해 더 확실히 이해할 수 있고, 그 중에 어느 튜닝이 효과가 있을지에 대해서도 좀 더 확실히 판단할 수 있다.

- 리팩토링하는 동안에는 단기적으로 소프트웨어가 느려지지만, 최적화를 거치면서 튜닝하기가 훨씬 쉬워져서 결과적으로는 소프트웨어가 더 빨라진다.