기존 시스템을 현대화함에 있어서 Copilot은 먼저 증거를 정리합니다.

1.5 시대의 Java 프로젝트를 최신 머신으로 처음 끌어왔을 때 가장 먼저 떠오른 것은 코드 문제가 아니라 증거 문제였습니다. 빌드를 재현할 수 있는지, 테스트 출력이 동일한지, 실패 지점이 JVM, 이미지 또는 소스 코드에서 나오는지 여부 등이 "리팩토링 시작"보다 먼저 진행하는 방법을 결정합니다. 오래된 시스템을 현대화할 때 가장 큰 두려움은 변화가 느리다는 것이 아니라, 변화 후에 어떤 일이 일어났는지 알 수 없다는 것입니다.

먼저 장면을 수정한 다음 후속 작업이 의미가 있을 것입니다. 해당 단계에서 가장 중요한 것은 IDE에서의 완성이 아니라 반복적으로 실행될 수 있는 상자입니다. 이전 JDK, 이전 빌드 도구, 이전 입구 및 이전 테스트 명령이 모두 Docker에 잠겨 있습니다. 다음과 같은 명령은 보기 좋지는 않지만 작동합니다.

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

이 명령에는 단 하나의 기능만 있습니다. "오늘의 실패"를 재생 가능한 증거로 수정하는 것입니다. 그것이 없다면, 이후의 모든 성공은 단지 관용적인 상황의 결과일 수도 있습니다. 여기서 Copilot의 역할도 매우 명확합니다. 이는 판단을 대체하는 것이 아니라 추적을 정렬하는 데 도움이 됩니다. 긴 로그에서 반복되는 오류, 빌드 스크립트에서 서로 에코되는 경로, 이전 테스트에서 반복되는 여러 항목을 모두 대략적인 선별에 먼저 사용할 수 있습니다. 걸러내는 것은 결론이 아니라 시작하기 위한 지도이다.

실제로 칼 아래로 들어갈 때가 되었을 때, 변화의 영역은 매우 좁을 것이다. 오래된 프로젝트를 뒤집는 가장 쉬운 방법은 패키지명, 빌드, 엔트리, 테스트를 한꺼번에 바꾸는 것이다. 결국 어느 단계에서 시스템이 손상되었는지조차 알 수 없습니다. 보다 안정적인 접근 방식은 먼저 가장 작은 간격을 포착하는 것입니다. 예를 들어 오래된 입구를 어댑터 레이어로 덮고 먼저 새로운 도구 체인이 기존 세계 외부에 서서 구조를 명확하게 볼 수 있도록 허용한 다음 천천히 들어갑니다. Copilot은 가져오기 채우기, 구성 이동, 반복되는 조각 추출 및 임시 테스트 뼈대 생성과 같은 이러한 종류의 기계적 작업을 처리하는 데 매우 적합합니다. 모델이 이러한 작업을 수행하도록 하면 효율성이 실제로 높아집니다. 하지만 이 솔기를 잘라야 하는지, 자른 후에 어떤 행동을 보존해야 하는지 결정하는 것은 여전히 ​​사람들에게 달려 있습니다.

테스트를 할 때도 겉모습에 속기 쉽습니다. 오래된 테스트를 통과했다는 것은 현대화가 안전하다는 것을 의미하는 것이 아니라 특정 역사적 행위가 아직 깨지지 않았다는 것을 의미할 뿐입니다. 많은 오래된 프로젝트의 테스트는 비즈니스 의미론적 사양보다는 동작 스냅샷에 더 가깝습니다. 녹색은 단지 녹색일 뿐이며 "시스템을 이해한다"는 의미로 직접적으로 해석될 수는 없습니다. 변환 중 가장 중요한 작업 중 하나는 각각의 작은 절개 부분에 새롭고 더 좁은 테스트 경계를 추가하여 테스트가 "역사적 유산"에서 "현재 제약 조건"으로 점차 변경되도록 하는 것입니다. Copilot은 오래된 주장을 분석하고, 템플릿을 완성하고, 중복 테스트 셸을 출시하는 데 도움을 줄 수 있습니다. 그러나 테스트에서 어떤 의미를 유지해야 하며 모델은 시스템에 대한 결정을 내릴 수 없습니다.

고고학적 근대화에서 가장 신뢰할 수 있는 분업은 실제로 매우 간단합니다. 환경과 통나무는 사실을 확인하는 역할을 담당하고, Copilot은 벽돌을 옮기고 번역하는 역할을 담당하며, 사람들은 어떤 역사를 보존해야 하고 어떤 역사를 잘라야 하는지 결정하는 역할을 담당합니다. 시스템의 과거를 설명하기 위해 모델이 배열되면 증거보다 추측이 더 설득력 있는 경우가 많습니다. 증거 관리 및 기계적 구성의 위치로 되돌리면 진정으로 유용한 보조자처럼 됩니다.