[레거시 코드 활용 전략] CH7 코드 하나 바꾸는 데 왜 이리 오래 걸리지?

2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경

2020/02/04 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH2 피드백 활용

2020/02/06 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH3 감지와 분리

2020/02/07 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH4 봉합 모델

CH5 는 단순한 테스트 도구와 관련된 이야기라 다루지 않습니다~

2020/02/10 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH6 고칠 것은 많고 시간은 없고 - 1

2020/02/15 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH6 고칠 것은 많고 시간은 없고 - 2

 

ch 7 - 코드 하나 바꾸는 데 왜 이리 오래 걸리지?

코드를 변경하는 데는 많은 시간이 걸린다.

불명확한 코드를 가지고 작업하는 프로젝트에서 변경을 수행하려면 많은 시간이 걸린다.

모든 분기와 반복을 이해하고 의존 관계를 분석해야 하기 때문이다.

코드 이해하기

코드의 양이 늘어나면 코드 전체를 이해하고 검사하는 데 한계를 느낄수밖에없다.

이는 어느 정도는 불가피한 상황이다.

꾸준하게 관리되는 프로젝트도 마찬가지다.

하지만 레거시 코드와 관리되는 프로젝트는 결과론 적으로는 다를 수밖에 없다.

꾸준하게 관리되는 프로젝트는 변경에 대한 파악이 끝나고 나면 작업 자체는 간단하게 끝난다.

하지만 레거시 프로젝트는 파악이 다 끝났지만 변경을 시작하지도 못하는 경우도 허다하다.

그렇기 때문에 적절한 크기를 유지하고, 네이밍에 신경을 쓴다면 코드 변경 작업을 신속하게 수행할 수 있다.

지연 시간

지연 시간이란 변경을 수행하고 그 변경에 대한 피드백을 받을 때까지의 시간을 말한다.

보통 우리는 코드를 변경하고, 빌드 하고, 결과를 확인한다.

불행하게도 이러한 시간이 길어지면 길어질수록 보통은 집중력이 끊기기 마련이다.

우리는 이러한 시간을 제거하여 빨라진 피드백을 활용하여 다양한 시험을 할 수 있으며, 더욱 많은 행동들을 할 수 있다.

그렇다면 우리는 왜 항상 이런 식으로 일을 하지 못하는 걸까?

컴파일 언어의 특징상 의존 관계가 많은 걸림돌이 된다.

작업 대상 코드를 컴파일하기 위해 관심이 없는 다른 코드도 함께 컴파일 해야 하기 때문이다.

의존 관계 제거

객체지향 언어에서 가장 먼저 할 일은 테스트 코드 안에서 클래스의 인스턴스를 생성하는 것이다.

불행하게도 레거시 코드 같은 경우는 테스트 코드 내부에 클래스를 집어넣는 것조차 힘든 일일 수 있다.

지나치게 거대한 클래스, 많은 의존관계 등이 문제다.

이러한 의존 관계를 제거한다면 빠른 컴파일과 빌드 과정을 얻을 수 있고, 이것은 빠른 피드백으로 이어질 수 있다.

빌드 의존 관계

객체지향 시스템에서 신속하게 빌드 해야 할 클래스들이 있다면, 가장 먼저 해야 할 일은 어떤 종류의 의존 관계가 있는지 찾는 것이다.

여기서 가장 포인트가 되는 것은 재컴파일돼야 하는 클래스를 최소화하는 것이다.

특히나 외부 리소스(DB, 네트워크) 경우에는 인터페이스를 통해 분리한다면, 해당 리소스가 변경되더라도 재컴파일이 필요가 없다.

또한 패키지 별로로 의존 관계를 제거하고 다수의 패키지로 분산시켜 빌드 시간을 줄일 수도 있다.

문제는 패키지 개수가 늘어나면서 분석에 많은 시간이 들 수도 있다.

하지만 코드를 조사하는 시간을 늘어나지만 변경 작업은 훨씬 쉬워지기 때문에 가치가 있는 행동이다.