[개요] 어디에나 레거시는 있다.
오랜 기간 개발자로 일하며 그렇게 많은 회사를 경험한것은 아니지만, 지금까지 진행했던 여러 인하우스 개발을 토대로 느낀바는 어디에나 레거시가 존재한다는 것이었다.
그리고 레거시가 만들어지는 문제는 실로 다양했는데 약간의 기술 부채도 눈덩이처럼 불어나 결국 미래의 우리가 건들이기 힘든 소스로 변모하는 것 같다.
이 기능은 뭐지?
레거시 소스를 접하면서 제일 많이 떠오른 생각이다.
사실 나도 주니어 시절이나 개발에 대한 심도있는 고민이 있던게 아니라면 늘 편하고 쉬운길을 찾기 마련이라고 생각한다.
레거시 소스도 이와 같은것 같다.
조금의 고민, 시간
꽤 오랜기간 개발자로 일하면서 다양한 회사, 프로젝트를 경험했다.
그리고 그 기간 동안 느낀건 어디를 가나 기술부채는 쌓이기 마련이고, 꼬여버린 스파게티는 있다는 것이었다.
이건 내가 지금까지 겪은 레거시와 해결 그리고 정신론적인 이야기다.
자신감 주도 개발?
지금까지 겪어본 레거시의 문제점을 꼽자면 가장 큰건 테스트코드가 없다는 거였다.
경험 기반, 지식 기반으로 코드를 수정/배포 하는데 이론상 멋있지만 잦은 휴먼오류/사이드 이펙트가 발생하는 문제점이 있다는게 크게 다가왔다.
때문에 난 이걸 자신감(근자감) 주도 개발이라 생각하고 레거시를 벗어나는 첫 걸음은 테스트였다.
기술부채 코드의 문제 1 - 응집도 엉망
레거시 코드를 보면 대다수 문제인게 응집도와 책임이 엉망이라는 점이었다.
때문에 단위 테스트가 어렵고 오류 발생시 연관관계 파악이 상당히 어렵다.
Legacy Oh… Legacy
레거시 코드란 뭘까? 단순히 오래된 코드일까?
개발자로 회사를 다니다 보면 정말 많은 케이스의 레거시 코드를 마주할 수 있다.
정말 많은 레거시가 존재하지만 대표적으로 아래 케이스로 정리가 되는것 같다.
지속적으로 쌓인 기술부채는 눈덩이처럼 불어나 개발자의 생산성을 낮추고 테스트 하기 어려운 코드와 이로 인해 작은 수정에도 많은 사이드 이펙트를 경험할 수 있다.
내가 지금까지 길다면 긴? 회사 생활 중 만났던 레거시의 유형과 이를 풀어간 방법에 대해서 이야기 해보고자 한다.
외부 종속성에 강하게 결합된 클래스
클래스와 DI 기반의 코드를 개발하다 보면 자연스럽게 여러 객체를 주입받고 사용하게 된다.
해당 과정을 바람직 하다고 말할 수 있지만 외부 상태를 가지는 클래스를
