오래된 시스템을 현대화하려면 먼저 호환성 사다리가 필요합니다.
Copilot의 정말 유용한 부분은 환경, 입구, 테스트 및 경계를 레이어별로 끌어내는 것입니다.
기존 시스템을 먼저 현대화하고 호환성 사다리를 구축하세요.
20년 전 처음 자바 프로젝트를 열었을 때 가장 먼저 본 것은 코드 냄새가 아니라 나이 냄새였다. build.xml은 여전히 있지만 pom.xml은 없습니다. 디렉토리 구조도 구식이고, 테스트 입구도 구식이며, "실행 가능한 제품을 다시 빌드할 수 있는지 여부"까지 재확인해야 합니다. 이 단계에서 가장 흔한 실수는 클래스와 메소드에만 집중하고 현대화를 실제로 방해하는 것이 환경과 진입이라는 점을 무시하는 것입니다.
오래된 시스템을 현대화할 때 가장 먼저 해야 할 일은 호환성 사다리를 구축하는 것입니다. 사다리의 기초에는 일반적으로 단 한 가지만 있습니다. 즉, 기존 규칙 내에서 기존 시스템을 안정적으로 실행하고 바람직하게는 타임캡슐 역할을 하는 것입니다. Docker, 이전 JDK, 이전 빌드 도구, 이전 테스트 명령 등은 투박해 보이지만 매우 효과적입니다. 이 기반이 올바르지 않은 한 이후의 모든 변경 사항은 새로운 소음과 혼합됩니다. 손상된 코드인지, 손상된 JVM, 이미지, 아키텍처 및 플러그인인지 알 수 없습니다.
그런 다음 다리를 선택할 차례였습니다. 브리지의 목표는 매우 구체적입니다. 한쪽 끝은 이전 소스 코드에 연결되고 다른 쪽 끝은 새 시스템에 연결됩니다. 이 프로젝트는 결국 Java 8과 Gradle 7.6으로 넘어갔고, 이는 양쪽 끝의 제약에 갇혔습니다. Java 17은 더 이상 Java 1.5의 소스 코드를 컴파일할 의향이 없으며 Java 6은 ARM64의 기본 환경에서 실행될 수 없습니다. 연결이 잘못되면 현대화가 도구 체인에 갇힐 것입니다. 브리지가 올바르면 후속 마이그레이션이 단계별로 진행될 수 있습니다.
여기서 가장 유용한 점은 대형 모델이 구성 및 번역을 수행하도록 하는 것입니다. Ant 로직을 Gradle로 변환하고, 디렉토리를 이전 레이아웃으로 다시 매핑하고, 반복적이고 기계적인 구성을 제거하는 데 도움이 될 수 있습니다. 예를 들어 소스 코드 디렉터리가 이전 경로를 명시적으로 가리키도록 하고 이전 main() 테스트를 실행하는 사용자 지정 작업을 추가합니다.
java {
sourceCompatibility = JavaVersion.VERSION_1_5
targetCompatibility = JavaVersion.VERSION_1_5
}
sourceSets {
main {
java {
srcDirs = ['java']
}
}
}
tasks.register('runLegacyTest', JavaExec) {
mainClass.set(project.findProperty('mainClass'))
classpath = sourceSets.main.runtimeClasspath
}
이 구성의 중요성은 구세계의 규칙을 명시적으로 만드는 것입니다. 오래된 프로젝트에서 가장 골치 아픈 것은 능력의 부족이 아니라 습관 속에 숨어 있는 능력인 경우가 많습니다. 테스트는 main() 항목을 통해 진행되며, 소스코드는 이전 디렉터리에 위치하며, Ant 시대의 경로를 가정하여 빌드가 작성됩니다. 여기서 Copilot은 시간을 절약할 수 있지만 판단 시간이 아닌 번역 시간을 절약해줍니다.
판단 시간은 아웃소싱할 수 없습니다. Gradle 8은 더 최신이고 Java 17은 더 현대적이며 바로 위로 점프하는 것도 더 깔끔해 보이지만 이러한 옵션은 이전 소스 코드와 이전 테스트의 제약 조건을 동시에 충족하지 못할 수 있습니다. 현대화에서 가장 큰 두려움은 도구 업그레이드를 진행으로 간주하고 명령 실행을 시스템 이해로 간주하는 것입니다. 프로젝트가 운영 기준을 달성하지 못하는 한 친환경 테스트는 승리로 간주되지 않으며 당분간 노출된 표면에 도달하지 않는 것으로 간주될 수 있습니다.
내가 더 신뢰하는 접근 방식은 먼저 문제를 실행 가능 여부, 편집 가능 여부, 테스트 가능 여부, 수정 가능 여부의 네 가지 수준으로 나누는 것입니다. 첫 번째 레벨은 장면 재현, 두 번째 레벨은 브릿지 결정, 세 번째 레벨은 이전 테스트에서 저장한 내용 확인, 네 번째 레벨은 실제 리팩토링입니다. Copilot은 처음 두 수준에서 특히 유용합니다. 이는 로그 및 디렉토리 구조를 따르는 실제 작업에 적합하고 조각난 단서를 판독 가능한 지도로 모으는 데 적합합니다. 네 번째 수준에서 모델은 운송 및 안내만 담당해야 하며 사람들은 결정을 내리기 위해 사람에게 의존해야 합니다.
기존 시스템을 현대화한 가장 가치 있는 결과는 “작동해야 하는” 여러 가지 항목을 "실제로 작동하고 왜 작동하는지 알고 있는 것"으로 바꾸는 것입니다. 일단 이 호환성 사다리가 확립되면 이후의 해체에는 리듬이 있을 것이고 변화에는 경계가 있을 것입니다. 코파일럿은 이때 최전선에서 손전등을 들고 나이, 입장, 의존성을 살펴보는 조수와 같다. 실제로 방향을 결정하는 것은 낡은 체제의 역사에 대한 판단이다.
What to read next
Want more posts about 后端?
Posts in the same category are usually the best next step for reading more on this topic.
View same categoryWant to keep following #AI?
Tags are useful for related tools, specific problems, and similar troubleshooting notes.
View same tagWant to explore another direction?
If you are not sure what to read next, return to the homepage and start from categories, topics, or latest updates.
Back home