레거시 코드란 .
오래된 코드를 뜻한다.
모든 코드들은 시간이 지남에 따라 레거시 코드가 되기 마련이다.
기술적으로도 당연히 낙후된 기술을 쓸 가능성이 높다.
그렇기 떄문에 레거시 코드를 어떻게 바라보고 어떻게 다뤄야 하는가 일종의 에티튜드 를 살펴보자.
- 존중하자.
나쁘다, 구조적으로 한계가 있다. 는 아이러니 하게도 그 코드 덕분에 서비스가 존재한 기둥이기도 하다.
명심해야할것은 이세상에 비난받아 마땅한 코드는 없다.
그러나 개선하기 힘든 코드는 있다.
그렇다면 개선하기 어려운 코드를 개선하기 위한 전략으로는 무었이 있을까?
- visualization ( 가시화 ) 하는것이 굉장히 효과적인 전략중의 하나이다.
입사후... 레거시 Case by Case
이미 레거시 시스템이 있다는 전재하에.
- 레거시 시스템의 main 개발자가 있는경우가 있고, 메인개발자는 없는데 보조개발자만 있는경우에
해당 개발자가 제품의 충분한 knowaloge 를 갖고 있지 못한다던지. - 제품 초기단계에 외주를 줘서 누가 만든진 모르겠지만 그 제품을 가지고 실제 서비스를 운영해야 한다던지.
상황은 다 다를것같다. 하지만 이들은 공통점을 갖고있다.
서비스를 지속해야 하기때문에 개선되고, 바뀌어야하는데. 수정하기 힘든상황에서 발생된다.
성공적인 포팅이 이루어지기 힘든이유는 왜일까 하면 코드분석이 제대로 되지 않아서다. 전체적인 아키텍처를 포함해 모든부분이다.
그럴때 제일 많이 나오는 답은 다음과 같다.
" ㅇㅓ 이 앱은 엉망입니다. 도저히 개선할수가 없어요. 재개발 만이 유일한 방법입니다."
생각보다 많은 케이스다.
이렇게 되었을때 회사내에 여러 이해관계자들 입장에서는
" 어 개발자가 이제품엔 답이없어. 재개발을 해야해." 라는 답변보단 구체적인 답변이 필요하다.
그렇지 않고서야 문제가 구체적이지 않고 일단. 추상적인 문제 제기가 되어버리기 때문이다.
" 엉망이야 " 라는건 사실 아무도 모른다.
실제로 그런 피드백을 주는 개발자들과 이야기를 나누다 보면,
구체적으로 얼마나 엉망인지 , 무엇이 엉망인지. 왜 재개발 밖에 답이없는지 명확하게 제시하는 개발자는 매우 드물다.
막상 하나하나 같이한번 레거시를 봐보자 하고 옆에 붙어 페어 프로그래밍을 하다보면.
재미있는 현상이 나타난다.
바로 => 그코드를 제대로 분석해본적이 없는경우다.
겉 면만 얄팍하게 살펴보고 그 코드가 싫어서이다 "애초에 그문제를 정확하게 파악하기 싫은 case 다"
그게 방어기재건, 뭐든간에 스스로 감정이 들어간 상태에선. 정확한 솔루션을 낼 수가 없다.
추상적으로 이코드는 엉망이에요 라는 피드백을 줄 수밖에 없는것.
사실 개인적으로 매우 이해가 가고 너무나 공감한다.
하지만 이 문제를 이해하는 차원과, 해결하는 솔루션을 만드는건 다른 것임을 명심해야 한다.
그렇다면 왜? 분석하기가 힘든가.
레거시 코드 분석 실패의 이유.
몇가지 유형이 있다.
1.기술 난이도가 높은 코드 .
레거시의 코드가 생각보다 높은난이도의 코드인 경우이다.
이전 개발자가 하필 나 보다도 역량이 높은 경우에 발생한다.
이런코드는 어떻게 분석해야 할까?
"솔직하게 역량 한계를 인정하고 공개한 후 함께 해결책을 찾아라."
내부에서 찾던 외부에서 찾던. 솔루션을 찾기 위한 활동을 내 역량을 높히는 활동과 함께 병행해야한다.
2. 잘못된 구조로 규모가 커진 코드
scale 이 커질것을 감안하지 못한 구조에서 커져버린 예다.
흔히 엔터프라이즈 급은 아니더라도, 아키텍처나 구조를 잡을 물리적인 시간이라던지.
기술의 부채를 극복하기 위한 활동을 갖지 못해서 점점점. 구조가 커진것이다.
이게 대부분의 문제있는 레거시의 케이스다.
하지만 보통의 레거시 코드는 차분히 보고 또 보다보면 풀리기 마련이다.
그러기 위해선 다음과 같은 마음가짐과 전략이 필요하다.
3. 비용이 너무 많이들어가 있는 솔루션
트래픽은 없는데 서버비용이 흔치 않은 가격이 매달 지불되는상황 인데, 얼마든지 무료 오픈소스나,
보다 저렴한 리소스를 고려하지 않고 개발된것 같은 솔루션일때 발생된다.
아마존 웹서비스에서 한달에 600~700 달러씩 기부하는 셈이고 1년이면 1000 만원에 가까운돈이 나가는 셈이다.
마음가짐
" 코드에 감정을 담지마라."
" 개발자의 역할은 제품을 만드는것이다."
" 좋은 코드는 좋은 제품을 만들기 위한 요소 중 하나일뿐 좋은 제품을 만들기 위한 필수조건은 아니다."
전략
엑셀과 같은 문서에 레거시의 모든것을 담는것이다
단계별로 개선 전략을 세워야 하며
재개발시 소요 비용을 산정해야 한다.
여기서 핵심은
"이해관계자 들이 공감하고 보기 쉽게 구체적인 문제들을 시각화 하는것이다."
- 모듈화 한다면 제거될 코드 40 %
- 문서화 되어있지 않은 비즈니스 로직 20 %
- 단계적으로 개선할 수 있는 코드 20 %
- 모듈 종속성으로 최신 버전으로 업데이트할 수 없는 라이브러리 4개 (전체의 25%)
- 중복코드를 제거하려면 얼마나 걸릴것 같고,
- 비정상적인 비즈니스 로직을 수정할려면 얼마나 걸릴것 같고,
- 기존코드와 병행할수 있는 부분들은 어떤 부분들이 있고,
- 병행하지 못하는 부분들은 어떤 부분들이 있는지.
이런 비용들을 시각화해서 정리해 보면
total 완전히 재개발 하는것과, 점진적 으로 재개발하는것 , 기존 레거시를 그대로 유지하면서
거기에 새로운 기능들을 계속 업데이트 하면서 운영하는것
이 세가지를 가지고 의사결정권자 에게 결정할수 있도록 하는것이 개발자의 역할이다.
그런 측면에서 감정을 배제하고
전략을 세우지 않는다면,
조그마한 기능이 왜이렇게 오래걸리지 ? 개발자의 역량에 문제가 있는것은 아닌지 하나씩 오해들이 겹겹이 쌓일수가 있기 떄문에 문제를 충분히 가시화 하고, 최대한 잘게 쪼개고 왜 오버헤드가 생기는지
가시화 하는것이 전략이다.
