레거시 코드를 대하는 법

안녕하세요. 이번 주제는 레거시 코드 리팩터링입니다.

보통 회사의 창립부터 같이 하지 않았다면 서비스되고 있는 코드들은 다른 이의 코드일 것입니다.
또한 높은 확률로 회사가 성장하며 요구사항의 추가가 되고 그로 인해 남의 코드에 붙이고 붙이고 가 될 것입니다.

이런 메서드들은 대개 중요한 일을 하고 있으며 코드의 로직을 제대로 이해하기는 오랜 시간이 걸립니다.
그러다 해당 메서드의 성능상 문제, 응답속도를 개선하기 위한 작업 폭탄이 제 차례에 다가올 수 있습니다.

이럴 때 어떻게 대처를 해야 하는지 제 기준으로 적어보았습니다.

1. 코드의 목적 파악하기
2. 리팩터링, 성능 개선하기

1. 코드의 목적 파악하기

먼저 코드의 목적을 파악을 해봅시다.
테스트 코드나 문서가 잘 정리되어 있다면 양호하겠지만 그럴 경우가 아니라면 코드의 의도를 파악해야 합니다.
코드의 처음 목적은 하나였겠지만 현재의 형태는 몸을 키웠기에 사이드 이펙트를 발생시킬 수 있습니다.

슈도코드

해당 메서드의 목적은 댓글 작성 후 이벤트 몇 개를 발생시킵니다.
코드의 목적을 확인했다면 이제 성능 개선 준비인 문제점을 확인해 볼 수 있습니다.


APM 등의 정보를 확인할 수 있는 환경이면 베스트이겠지만 그렇지 않다면 네트워크 호출, 루프 등을 확인해 봅니다.

목적과 문제점을 파악하기 쉬운 방법은 슈도 코드를 작성해보는 것입니다.
이를 통해 어디서 네트워크 호출이 많은지 시간 복잡도 등을 줄일 수 있을지를 고민해 볼 수 있습니다.

2. 리팩터링, 성능개선 하기

저는 리팩터링 후의 모습도 슈도 코드로 작성을 해봅니다.
(복잡한 예제가 떠오르지 않아 리팩터링이 쉬울 수 있습니다..)

해당 예제에서는 댓글 작성에만 포커스를 맞추고 이외의 로직은 비동기 이벤트로 따로 분리할 수 있겠습니다.
내부의 메서드들 또한 메서드 분리 등으로 목적에 맞게 작은 메서드 등으로 쪼갤 수도 있습니다.

(마틴 파울러의 리팩터링에 많은 방법들이 제시되고 있습니다.)

리팩토링 Refactoring

ORM을 사용하지 않아도 N+1문제는 기존 코드에서 발견할 수 있습니다.
처음 서비스 시작 시에는 쿼리량이 많지 않아 사용 가능했지만 점차 서비스가 커지면 말 그대로 1+ N의 쿼리가 나올 수 있습니다.

이를 위해 index를 활용한 join 등을 사용해 성능 개선을 도울 수 있습니다.
물론 상황에 따라 많은 join이 성능을 더 나쁘게 할 수 있습니다. 적절한 판단이 필요합니다.

테스트 코드 작성하기

코드를 분석했다고 해도 테스트 코드를 통해 내가 손대기 이전과 동일하게 작동하는지 확인은 필수입니다.
나를 위해서 또 남을 위해서.

마무리

개인적으로 코드를 개선할 일이 생길 때, 들여다보는 것보다 슈도 코드, 시퀀스 다이어그램 등을 사용하는 것이 더 빠르게 파악할 수 있었습니다.
거창하게 하는 것이 아닌 본인의 이해를 돕는 면에서는 좋은 방법 같습니다.

ps. 본인이 작성한 코드는 언젠가 레거시가 됩니다. 레거시는 항상 그럴 수밖에 없는 이유가 있습니다.

References

하쿠나 입장 API 개선하기 - 괴물 API 리팩토링과 성능개선하기