[레거시 코드 활용 전략] CH1 소프트웨어 변경

레거시 코드 활용 전략 (재출간판) 국내도서 저자 : 마이클 C. 페더스(Michael C. Feathers) / 심윤보,이정문역 출판 : 에이콘출판사 2018.09.28 상세보기

ch 1 - 소프트웨어 변경

소프트웨어를 변경하는 이유

1. 새로운 기능 추가
2. 버그 수정
3. 설계 개선
4. 자원 이용의 최적화

1.기능 추가와 버그 수정

지금 하는 것이 버그 수정? or 기능 추가?

• 고객 관점 : 내가 원하는 건 A 기능이 아니라 B기능 이야 → 버그 수정
• 개발자 관점 : B라는 새로운 기능

기술 및 개발 관점에서 버그 수정 / 기능 추가 보다 더 중요한 것은 ? → 동작 변경

새로운 동작을 추가하는 것과 기존 동작을 변경하는 것에는 큰 차이가 있음

기존 코드 변경 → 동작 변경

새로운 코드 추가 → 동작 추가

그러나 대부분 동작 변경 없이 동작을 추가하는 것은 힘들다

2. 설계 개선

소프트웨어 구조를 좀 더 유지 보수하기에 쉬운 구조로 변경하기 위해!

설계 개선을 자주 시도하지 않는 이유

• 동작 누락
• 원치 않는 동작

→ 버그!

동작 변경 없이 설계를 개선하는 행위 → 리팩토링

리팩토링 순서

1. 기존 동작이 정상적이라는 테스트 루틴을 작성
2. 테스트 루틴을 검증하면서 단계 진행

리팩토링 특징

• 기존 위험부담이 적은 소스 코드 재구성이나, 위험 부담이 큰 소스코드 재작성과는 다름!
• 코드 변경을 쉽게 하기 위해 테스트 루틴이 뒷받침되는 것이 바로 리팩토링
• 변경 관점에서 가장 중요한 것은 리팩토링 전후에 기능 변경은 없어야 함 → 하지만 구조 변경은 어쩔 수 없이 성능 변화를 가져오기 때문에 동작이 변경되기도 함

3. 최적화

'다른 무언가'를 변경할 때, 기존의 기능은 모두 동일하게 유지하면서 변경한다는 것에서는 리팩토링과 동일

리팩토링의 '다른 무언가' → 프로그램 구조

최적화의 '다른 무언가' → 프로그램이 사용하는 시간 / 메모리 등의 자원

4. 네가지 이유의 종합

	기능 추가	버그 수정	리팩토링	최적화
구조	변경	변경	변경	-
새로운기능	변경	-	-	-
기능	-	변경	-	-
자원 사용량	-	-	-	변경

기능 추가, 리팩토링, 최적화는 기존 기능을 그대로 유지

버그 수정도 일부 기능이 변경되지만 매우 작은 경우가 대부분

→ 결국 네 가지 사항 대부분이 기존의 동작을 그대로 유지하는 경우가 많음

그럼 정확성을 확인해야 하는 대상은 기존 변경 대상 코드에만 국한되는 것일까?

No! 변경 대상 코드에만 집중하다 보면 기존 동작이 변경될 수도 있다.

기존 변경 없음 ≠ 코드를 그대로 유지하는 것

기존 변경 없음 = 다른 동작 또한 유지하는지 확인하는 것

기존 유지돼야 하는 동작은 관리하기가 쉬움

그러나 그것이 다른 동작에 어떤 영향을 미칠지 파악하기가 어려움

5. 위험한 변경

기존 동작을 그대로 유지하면서 변경할 때 상당한 위험이 수반된다.

위험을 최소화하기 위해 3가지 질문을 해야 한다.

1. 변경해야 하는 것은 무엇인가?
2. 정확한 변경인지 어떻게 확인할 수 있을까?
3. 손상된 영역이 없는지 어떻게 확인할 수 있을까?

기존 메소드에 코드를 추가하여 메소드 수를 유지하는 것이 문제를 최소화하는 것일까?

No! 기존 메소드가 너무 비대해져 코드를 이해하기 어려운 지경에 이름

좋은 시스템 : 익숙해질수록 변경 작업에 확신을 가지는 시스템

나쁜 시스템 : 코드 변경 작업이 어려운 시스템

변경을 회피한다면?

개발자의 실력이 녹슬기 쉬움