오래된 코드를 현대화하려면 먼저 고고학이 필요합니다

오래된 코드에서 가장 어려운 점은 오래된 구문이 아니라 오래된 시대입니다. 프로젝트는 build.xml, 이전 JDK, 이전 테스트 프레임워크 및 이전 패키징 방법으로 채워져 있습니다. 표면적으로는 여러 개의 파일 더미처럼 보이지만 실제로는 역사적 가정이 겹겹이 쌓여 있는 것입니다. 코드 자체는 가장 바깥쪽 레이어일 뿐입니다. 실제로 전달을 방해하는 것은 이러한 가정이 여전히 존재하는지, 재현할 수 있는지, 변경 후 이전 동작이 손실되는지 여부입니다.

이것이 바로 '고고학’이 '변형’보다 앞선 이유이다. 먼저 빌드 파일을 살펴본 다음 종속성, 실행 환경, 테스트를 살펴보세요. 순서는 되돌릴 수 없습니다. build.xml은 여전히 ​​존재하지만 pom.xml은 존재하지 않습니다. 이러한 신호는 프로젝트가 Ant 시대에 살고 있음을 나타내기에 충분합니다. 코드를 컴파일할 수 있는지, 테스트를 실행할 수 있는지, 제품을 다시 빌드할 수 있는지 여부가 첫 번째 증거입니다. 여기서 모델의 가장 유용한 부분은 이전 코드에 대한 새 코드를 즉시 작성하는 것이 아니라 조각 더미에서 이러한 증거를 식별하는 것입니다.

환경도 먼저 고정해야 합니다. 오래된 코드에는 오래된 JVM, 오래된 컨테이너, 오래된 아키텍처 가정이 함께 제공되는 경우가 많습니다. 특히 크로스 아키텍처 환경에서 오늘날의 시스템에 직접 적용하면 문제가 발생할 때 새로운 소음이 쉽게 섞일 수 있습니다. 코드가 본질적으로 손상되어 있습니까? 아니면 문제를 일으키는 에뮬레이션, 미러링 및 도구 체인입니까? 현 단계에서 "동일한 코드를 동일한 환경에서 안정적으로 재현할 수 있다"는 것조차 달성할 수 없다면 이후의 모든 현대화 작업은 추측에 불과할 것입니다.

이 단계에서 AI의 가치는 분명합니다. 문자 수준 및 구조 수준 번역에 도움이 될 수 있습니다. Ant를 Gradle로 변환하는 것, 오래된 빌드 스크립트를 현재 유지 관리 가능한 형식으로 변환하는 것, 반복적인 XML 및 상용구를 더 명확한 위치로 이동하는 것 모두 모델에 맡기기에 좋은 후보입니다. 빠르고, 계속해서 시도할 의향이 있으며, 너무 사소하지도 않습니다. 하지만 심판용으로는 적합하지 않습니다. 어떤 경고를 먼저 보관할 수 있는지, 어떤 테스트가 실제로 거짓말을 하고 있는지, 어떤 모듈을 먼저 잘라야 하는지, 어떤 클래스만 패키징하고 적용해야 하는지 등을 설명합니다. 결국 사람이 결정해야 하는 것입니다.

테스트는 사람들을 속이는 가장 쉬운 방법입니다. 이전 프로젝트에서 테스트를 통과했다는 것은 시스템이 이해되었다는 의미가 아니라 일부 이전 동작이 현재 환경에 포함되어 있다는 의미일 뿐입니다. "완전 친환경"이라는 느낌은 더 큰 문제를 가리는 경우가 많기 때문에 위험합니다. 테스트에서 확인하는 것은 현재 보존해야 하는 비즈니스 의미 체계가 아니라 특정 시대의 구현 세부 사항입니다. 정말로 개혁하고 싶다면 가장 먼저 해야 할 일은 이러한 테스트를 '장식적인 안정감’에서 벗어나 그들이 무엇을 보호하고 있는지 다시 판단하는 것이다.

따라서 이러한 유형의 프로젝트에 대한 가장 안정적인 방법은 일반적으로 한 번에 다시 작성하는 것이 아니라 먼저 타임캡슐을 만들어 오래된 환경, 오래된 동작 및 오래된 종속성을 수정한 다음 가장 좁은 균열을 따라 제거하는 것입니다. 먼저 시스템을 재현 가능하게 만든 다음 반복적인 작업을 AI에 넘겨 번역한 다음 경계를 층별로 벗겨냅니다. 순서가 잘못되면 모델은 기존 프로젝트를 가속화하고 더 깊은 혼란에 빠지게 됩니다. 순서가 정확하다면 모델은 벽돌을 옮기고, 먼지를 청소하고, 증거를 비교하고, 사람들을 더러운 일에서 해방시키고 판단을 그들의 손에 맡기는 일을 담당하는 정말 유용한 고고학 조수와 같을 것입니다.