در مدرن سازی سیستم قدیمی، Copilot ابتدا شواهد را سازماندهی می کند

اولین باری که یک پروژه جاوا را از دوران 1.5 روی یک ماشین مدرن کشیدم، اولین چیزی که ظاهر شد مشکل کد نبود، بلکه مشکل شواهد بود. این که آیا می‌توان ساخت را بازتولید کرد، چه خروجی آزمایشی یکسان باشد، چه نقطه شکست از 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 مسئول جابجایی آجرها و ترجمه است، و مردم مسئول تصمیم‌گیری هستند که کدام تاریخ باید حفظ شود و کدام تاریخ باید قطع شود. هنگامی که یک مدل برای توضیح گذشته سیستم تنظیم می شود، اغلب حدس ها را قانع کننده تر از شواهد می کند. با قرار دادن آن در موقعیت مدیریت شواهد و سازمان مکانیکی، بیشتر شبیه یک دستیار واقعا مفید می شود.