소프트웨어 코드를 변경하는 네 가지 이유
기능 추가와 버그 수정
•
기존 코드를 변경해야 한다면 동작 변경으로 간주하고, 새로운 코드를 추가하고 이를 호출할 뿐이라면 동작 추가로 간주한다.
•
즉, 기존 코드를 변경하는 경우 버그 수정, 새로운 코드 추가 후 단순 호출인 경우 기능 추가로 간주한다.
설계 개선
•
소프트웨어의 구조를 좀 더 유지 보수하기에 쉬운 구조로 변경하고 싶을 때, 소프트웨어의 동작은 건드리지 않으면서 수행한다.
•
동작 변경 없이 설계를 개선하는 행위를 가리켜 리팩토링이라고 한다. 변경 관점에서 가장 중요한 점은 리팩토링 전후에 기능상의 변경이 없어야 한다는 점이다.
최적화
•
최적화는 리팩토링과 유사하지만 다르다.
•
리팩토링은 기존의 기능을 모두 유지하면서 프로그램 구조를 변경하지만 최저고하는 프로그램이 사용하는 시간이나 메모리 등의 자원을 변경한다.
네 가지 이유의 종합
기능 추가 | 버그 수정 | 리팩토링 | 최적화 | |
구조 | 변경 | 변경 | 변경 | - |
새로운 기능 | 변경 | - | - | - |
기능 | - | 변경 | - | - |
자원 사용량 | - | - | - | 변경 |
•
변경이 발생했을 때, 변경의 정확성을 확인해야 하는 범위는 그리 크지 않다. 변경 대상 코드에만 집중하면 되는 것이다.
•
하지만 꼭 그런 것은 아니다. 기존의 동작에 영향을 미치지 않았는지 확인해야 한다. 이는 매우 어렵다.
•
안전한 변경을 수행하기 위해서는 영향이 미치는 범위를 정확히 이해하는 것이 가장 중요하다.
위험한 변경
•
위험을 최소화하기 위해서는 다음의 세 가지 질문을 해야 한다.
1.
어떤 변경을 해야 하는가?
2.
변경이 정확하게 이뤄졌는지 어떻게 확인할 수 있는가?
3.
무언가를 손상시키지 않았는지 어떻게 확인할 수 있는가?
•
변경이 위험하다고 해서 피해선 안 된다. 맞서 싸워야 한다.
•
시간을 들여 코드를 분석하고 점검하며 그에 따라 올바른 방법으로 변경을 수행할 수 있게 노력해야 한다.
•
그렇다고 이것이 모든 작업의 정확성을 보증하지는 않는다. 어떻게 알 수 있을까?
