레거시 코드는 시간이 흐를수록 악화됩니다
레거시 코드는 와인처럼 숙성되지 않습니다. 방치하는 매일매일 더 나빠질 뿐입니다.
지난주, 저는 20분이면 끝날 문제를 디버깅하는 데 세 시간을 허비했습니다. 원인은 2019년에 만들어진 검증 모듈이었습니다. 사람들은 잘 작동하니까 그대로 두었습니다. 하지만 제대로 작동하지 않았습니다. 2020년에 작성된 "TODO: 리팩토링할 것"이라는 주석을 발견했습니다.
많은 이들이 레거시 코드를 선택적인 부채로 취급합니다. 시간이 나면 갚으면 된다고 생각하죠. 하지만 레거시 코드는 곰팡이와 같습니다. 퍼져 나갑니다. 주변의 모든 것을 오염시킵니다. 기다리면 기다릴수록 이를 청소하는 비용은 더 커집니다.
사이클은 예측 가능합니다:
- 지저분하지만 작동은 하는 기능을 물려받습니다.
- 작동시키기 위해
if문을 하나 더 추가합니다. - 6개월 후, 다른 누군가도 똑같이 합니다.
- 1년 후, 그 파일은 800줄이 되고 테스트는 하나도 없게 됩니다.
이 숨겨진 비용은 세 가지 방식으로 나타납니다:
- 속도가 저하됩니다. 코드를 작성하는 시간보다 문맥을 파악하는 데 더 많은 시간을 쓰게 됩니다.
- 버그가 늘어납니다. 로직이 엉켜 있어서 하나를 고치면 다른 것이 망가집니다.
- 온보딩이 실패합니다. 신입 개발자들은 왜 똑같은 로직이 일곱 군데나 존재하는지 이해하는 데 어려움을 겪습니다.
다음과 같은 위험 신호를 주의하세요:
- "HACK: 건드리지 마시오"와 같은 쓸모없는 주석.
- 여러 파일에 걸쳐 중복된 비즈니스 로직.
- 서비스들이 서로를 참조하는 순환 의존성.
모든 것을 새로 작성하지 마세요. 전체 재작성은 80%의 확률로 실패합니다. 대신 특성 테스트(characterization tests)를 활용한 점진적 리팩토링을 수행하세요.
다음 프로세스를 따르세요:
- 이상한 부분까지 포함하여 현재의 동작을 테스트로 캡처합니다.
- 그 동작을 바꾸지 않으면서 코드를 리팩토링합니다.
- 코드를 읽기 쉬워질 때까지 반복합니다.
- 실제 테스트가 확보된 후에만 동작을 변경합니다.
준수해야 할 규칙:
- 테스트 없이 리팩토링하지 마세요.
- 코드의 동작 방식을 바꾸는 개선은 피하세요. 버그가 클라이언트가 의존하고 있는 기능일 수도 있습니다.
- 조용한 코드는 그대로 두세요. 3년 동안 변경되지 않았고 아무런 문제를 일으키지 않는 모듈이라면 건드리지 마세요.
자주 만지는 코드에 에너지를 집중하세요.
Source: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h