리팩토링에 대한 일반적인 성능 우려

직관적인 설계 vs. 성능

• 리팩토링에 대한 일반적인 우려는 프로그램 성능에 미치는 영향이다.
• 리팩토링하면 소프트웨어가 느려질 수도 있는 것은 맞지만 동시에 성능 튜닝이 더 용이하도록 만든다.
• 빠른 소프트웨어를 만들기 위해서는 튜닝하기 쉽게 만든 후에 원하는 충분한 속도로 조정하는 것이 필요하다.

빠른 소프트웨어를 작성하는 접근 방식 3가지 경험 사례

1. 시간 예산 분배 (time budgeting) 방식

<aside>

설계를 여러 컴포넌트로 나누고, 각 구성 요소에 사용할 수 있는 자원 예산(시간, 메모리 등)을 미리 할당하는 방식이다.

이로써 각 컴포넌트는 주어진 자원을 초과하지 않도록 설계와 구현 과정에서 관리된다.

</aside>

• 특징
  • 해당 구성 요소는 예산을 초과해서는 안되지만, 예산자원을 교환하는 메커니즘은 허용된다.
  • 시성능과 관련된 시간 목표에 초점을 맞추어 설계가 진행된다.
• 심장 박동기와 같이 데이터가 늦게 전달되면 안되는 시스템에서는 필수적이다.
• 사내 정보 시스템과 같은 엄격한 실시간 성능이 요구되지 않는 환경에는 맞지 않는 기법이다.

2. 지속적 주의 (Constant Attention) 방식

<aside>

모든 프로그래머가 항상 소프트웨어 성능을 높이기 위해 할 수 있는 모든 노력을 기울이는 방식이다.

</aside>

• 특징
  • 모든 순간 성능을 고민하면 최적화된 결과를 얻을 것이라는 직관적인 기대를 주지만 실제로는 효과적이지 않다.
  • 성능을 개선하는 변경사항들은 보통 프로그램을 더 다루기 어렵게 만들며 이는 개발 속도가 늦춰지는 것으로 이어진다.
  • 만약 결과적으로 소프트웨어가 더 빨라질 수 있다면 가치가 있지만, 보통 그렇지 않다.
• 한계

  • 성능을 개선하기 위한 최적화가 프로그램 전반에 퍼지게 되는데, 각각의 개선은 프로그램의 특정한 동작에만 국한된다.

  • 정작 컴파일러, 런타임, 하드웨어의 작동 방식을 이해하지 못한채 작성하는 경우도 많다.

    → 기대에 못 미치는 성능을 초래한다.

+ It Takes Awhile to Create Nothing 아무것도 만들지 않는 데 시간이 걸린다.