레거시 코드는 시간이 흐를수록 악화됩니다

레거시 코드는 시간이 흐른다고 좋아지지 않습니다. 오히려 악화됩니다.

지난주에 버그 하나를 고치는 데 3시간을 썼습니다. 원래는 20분이면 충분했을 일입니다. 문제는 2019년에 만들어진 검증 모듈이었습니다. 모두가 "잘 작동하니까" 그냥 무시했습니다. 하지만 제대로 작동하지 않았습니다. 파일 안에서 2020년에 작성된 TODO 주석을 발견했습니다.

많은 사람이 레거시 코드를 선택적인 부채처럼 취급합니다. 시간이 나면 갚으면 된다고 생각하죠. 하지만 레거시 코드는 곰팡이에 더 가깝습니다. 곰팡이는 번식합니다. 시스템의 다른 부분까지 오염시킵니다. 방치하면 방치할수록 이를 청소하는 데 드는 비용은 점점 더 커집니다.

이는 악순환을 만듭니다:

• 엉망인 프로젝트를 물려받습니다.
• 기능을 구현하기 위해 if 문을 하나 더 추가합니다.
• 6개월 후, 다른 누군가도 똑같이 합니다.
• 1년 후, 그 파일은 800줄이 넘고 테스트는 하나도 없게 됩니다.

이 "작동하는" 코드에는 숨겨진 비용이 있습니다:

• 개발 속도가 떨어집니다. 코드를 짜는 시간보다 문맥을 파악하는 데 더 많은 시간을 쓰게 됩니다.
• 버그가 늘어납니다. 하나를 고치면 다른 것이 망가집니다.
• 온보딩이 어려워집니다. 신입 개발자들은 왜 로직이 여기저기 중복되어 있는지 이해하는 데 애를 먹습니다.

다음과 같은 위험 신호(red flags)를 주의하세요:

• 쓸모없거나 거짓 정보를 담은 주석.
• 서로 다른 파일에 중복된 비즈니스 로직.
• 순환 의존성과 높은 결합도.

모든 것을 다시 쓰려고 하지 마세요. 전체 재작성(Full rewrite)은 80%의 확률로 실패합니다. 비즈니스 측에서 새로운 기능을 기다리는 동안, 당신은 이미 존재하는 것을 다시 만드는 데 몇 달을 허비하게 됩니다.

특성 테스트(characterization tests)를 활용한 점진적 리팩터링을 사용하세요:

• 설령 이상하더라도, 테스트를 통해 현재의 동작을 캡처하세요.
• 그 동작을 바꾸지 않은 채 리팩터링하세요.
• 코드를 읽기 쉬워질 때까지 반복하세요.
• 그 후에야 실제 테스트를 통해 동작을 변경하세요.

함정에 빠지지 않으려면 다음 규칙을 따르세요:

• 테스트 없이 리팩터링하지 마세요.
• 리팩터링 중에 동작을 바꾸지 마세요. 버그가 클라이언트가 의존하고 있는 문서화되지 않은 기능일 수도 있습니다.
• 조용한 코드는 그대로 두세요. 어떤 모듈이 3년 동안 변경되지 않았고 아무런 문제를 일으키지 않는다면, 그냥 두는 것이 좋습니다.

자주 손대는 코드에 에너지를 집중하세요.

Source: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h