Eski sistemi modernleştirirken Copilot öncelikle kanıtları düzenler

1.5 döneminden kalma bir Java projesini modern bir makineye ilk kez aktardığımda, ortaya çıkan ilk şey kod sorunu değil, kanıt sorunuydu. Yapının yeniden üretilip üretilemeyeceği, test çıktısının aynı olup olmadığı, hata noktasının JVM’den, görüntüden veya kaynak kodundan gelip gelmediği, bunlar "yeniden düzenlemeye başlama"dan önce nasıl ilerleneceğini belirler. Eski sistemleri modernleştirirken en büyük korku, değişikliklerin yavaş olması değil, değişikliklerden sonra ne olduğunu söylemenin imkansız olmasıdır.

Önce sahneyi düzeltin, ardından sonraki eylemler anlamlı olacaktır. Bu adımdaki en değerli şey IDE’nin tamamlanması değil, tekrar tekrar çalıştırılabilen bir kutudur: eski JDK, eski derleme araçları, eski girişler ve eski test komutlarının tümü Docker’da kilitlenmiştir. Aşağıdaki gibi komutlar pek hoş olmasa da işe yarıyor:

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

Bu komutun tek bir işlevi vardır: “bugünün başarısızlığını” tekrar oynanabilir kanıtlara dönüştürmek. Bu olmadan, sonraki her başarı affedici koşulların sonucu olabilir. Copilot’un buradaki rolü de çok net. Bu, yargının yerine geçmek için değil, izlerin ayıklanmasına yardımcı olmak içindir: uzun günlüklerde tekrarlanan hatalar, derleme komut dosyalarında birbirini tekrarlayan yollar ve eski testlerde yinelenen birkaç girişin tümü, öncelikle kaba bir tarama için kullanılabilir. Elenen şey bir sonuç değil, başlangıç ​​için bir haritadır.

Aslında bıçağın altına girme zamanı geldiğinde değişim alanının çok dar olması gerekir. Eski projeleri tersine çevirmenin en kolay yolu paket adını, derlemesini, girişini ve testini aynı anda değiştirmektir. Sonuçta hangi adımın sistemi bozduğunu bile bilemezsiniz. Daha istikrarlı bir yaklaşım ilk önce en küçük boşluğu yakalamaktır: örneğin, eski girişi bir adaptör katmanıyla kapatın, önce yeni takım zincirinin eski dünyanın dışında durmasına ve yapıyı net bir şekilde görmesine izin verin ve ardından yavaşça içeri girin. Copilot bu tür mekanik işlerin üstesinden gelmek için çok uygundur: içe aktarmaları doldurma, konfigürasyonları taşıma, tekrarlanan parçaları çıkarma ve geçici test iskeletleri oluşturma. Bırakın bunları model yapsın, verimlilik gerçekten yüksektir; ancak bu dikişin kesilip kesilmeyeceğine ve kesildikten sonra hangi davranışın korunması gerektiğine karar vermek yine de insanlara kalmıştır.

Test söz konusu olduğunda görünüşe aldanmak da kolaydır. Eski testi geçmek, modernleşmenin güvenli olduğu anlamına gelmez, yalnızca belirli tarihsel davranışların henüz bozulmadığı anlamına gelir. Birçok eski projenin testleri, iş anlamsal spesifikasyonlarından ziyade davranışsal anlık görüntülere benzer. Yeşil sadece yeşildir ve doğrudan “sistemi anlamak” olarak yorumlanamaz. Dönüşüm sırasındaki en önemli eylemlerden biri, her küçük kesiğe yeni, daha dar test sınırları eklemek, böylece testin yavaş yavaş “tarihsel mirastan” “mevcut kısıtlamalara” dönüşmesidir. Copilot, eski iddiaların çözümlenmesine, şablonların tamamlanmasına ve yinelenen test kabuklarının kullanıma sunulmasına yardımcı olabilir. Ancak testte hangi anlambilimin korunması gerektiği ve modelin sistem adına karar vermesi mümkün değildir.

Arkeolojik modernleşmede en güvenilir işbölümü aslında çok basittir: Gerçeklerin çivilenmesinden çevre ve kütükler sorumludur, Tuğlaların taşınması ve tercüme edilmesinden Yardımcı Pilot sorumludur ve hangi tarihin korunması ve hangi tarihin kesilmesi gerektiğine karar vermekten insanlar sorumludur. Bir model sistemin geçmişini açıklayacak şekilde düzenlendiğinde, çoğu zaman kanıtlardan çok tahminleri daha ikna edici hale getirir; onu kanıt yönetimi ve mekanik organizasyon konumuna geri koyarsak, gerçekten yararlı bir asistana dönüşür.