- 새로운 기능의 추가
- 버그 수정
- 설계 개선
- 자원 이용의 최적화
- 새로운 동작을 추가하는 것과 기존의 동작을 변경하는 것에는 커다란 차이가 있다.
- 기존 코드를 변경해야 한다면 동작 변경으로 간주하고, 새로운 코드를 추가하고 이를 호출할 뿐이라면 동작 추가로 간주한다.
- 소프트웨어의 구조를 좀 더 유지보수하기에 쉬운 구조로 변경하고 싶을 때, 일반적으로 동작은 건드리지 않는다.
- 이 과정에서 어떤 동작이 제거되면 '버그'라고 부를 때가 많다.
- 자주 시도하지 않는 주요 이유 중 하나는 특정 동작이 누락되거나 원치 않는 동작이 만들어지기 쉽기 때문이다.
- 동작 변경 없이 설계를 개선하는 행위를 리팩토링이라고 한다.
- 리팩토링은 소프트웨어의 기존 동작이 변경되지 않음을 확인하는 테스트 루틴을 작성하고, 이를 검증하면서 단계별로 작업을 진행함으로써 유지 보수성을 개선할 수 있다.
- 핵심은 코드 변경을 쉽게 하기 위한 테스트 루틴의 뒷받침을 받는 것이다.
- 변경 관점에서 리팩토링의 중요한 것은 기능상의 변경이 없어야 한다는 것이다.
- 리팩토링과 최적화는 소프트웨어를 변경하면서 기존의 기능은 모두 동일하게 유지하며 '다른 무언가'를 변경한다는 공통점을 가진다.
- 리팩토링에서는 '프로그램 구조', 최적화에서는 '시간이나 메모리 등의 자원'을 가리킨다.
| 기능 추가 | 버그 수정 | 리팩토링 | 최적화 | |
|---|---|---|---|---|
| 구조 | 변경 | 변경 | 변경 | - |
| 새로운 기능 | 변경 | - | - | - |
| 기능 | - | 변경 | - | - |
| 자원 사용량 | - | - | - | 변경 |
- 소프트웨어에 새로운 기능을 추가할 때는 일반적으로 기존 기능을 건드리지 않는 것이 보통이다.
- 기능 추가, 리팩토링, 최적화는 모두 기존 기능을 그대로 유지한다.
- 핵심은 어떻게 기존의 동작에 영향을 미치지 않고 유지할 수 있을지 고민해야 하는 것이다.
- 어떤 동작을 변경할 때 다른 동작은 변경되지 않음을 확인할 수 있어야 하는데, 이것이 매우 어려운 일이다.
- 어떤 변경을 해야 하는가?
- 변경이 정확하게 이뤄졌는지 어떻게 확인할 수 있는가?
- 무언가를 손상시키지 않았는지 어떻게 확인할 수 있는가?
- 위험이 따르는 변경이라면, 얼마나 위험을 감수할 수 있을까?