Trong quá trình hiện đại hóa hệ thống cũ, Copilot trước tiên sắp xếp bằng chứng

Lần đầu tiên tôi đưa một dự án Java từ thời 1.5 lên một chiếc máy hiện đại, điều đầu tiên nảy ra không phải là vấn đề về mã mà là vấn đề về bằng chứng. Liệu bản dựng có thể được sao chép hay không, liệu đầu ra thử nghiệm có giống nhau hay không, liệu điểm lỗi đến từ JVM, hình ảnh hay mã nguồn hay không, những điều này sẽ xác định cách tiến hành sớm hơn trước khi “bắt đầu tái cấu trúc”. Nỗi sợ lớn nhất khi hiện đại hóa các hệ thống cũ không phải là những thay đổi diễn ra chậm mà là không thể biết được điều gì đã xảy ra sau những thay đổi.

Hãy sửa cảnh trước, sau đó những hành động tiếp theo sẽ có ý nghĩa. Điều có giá trị nhất ở bước đó không phải là việc hoàn thành trong IDE mà là một hộp có thể chạy lặp đi lặp lại: JDK cũ, công cụ xây dựng cũ, lối vào cũ và lệnh kiểm tra cũ đều bị khóa trong Docker. Các lệnh như sau không đẹp nhưng chúng hoạt động:

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

Lệnh này chỉ có một chức năng: sửa “lỗi hôm nay” thành bằng chứng có thể xem lại được. Nếu không có nó, mọi thành công tiếp theo có thể chỉ là kết quả của những hoàn cảnh vô tình được tha thứ. Vai trò của phi công phụ ở đây cũng rất rõ ràng. Nó không phải để thay thế sự phán xét mà để giúp sắp xếp các dấu vết: các lỗi lặp lại trong nhật ký dài, các đường dẫn lặp lại lẫn nhau trong các tập lệnh xây dựng và một số mục lặp lại trong các thử nghiệm cũ đều có thể được sử dụng để sàng lọc sơ bộ trước tiên. Những gì được sàng lọc không phải là một kết luận mà là một bản đồ để bắt đầu.

Khi đến lúc thực sự phải phẫu thuật, phạm vi thay đổi phải rất hẹp. Cách dễ nhất để lật đổ các dự án cũ là thay đổi tên gói, bản dựng, mục nhập và kiểm tra cùng một lúc. Cuối cùng, bạn thậm chí không thể biết bước nào đã phá vỡ hệ thống. Một cách tiếp cận ổn định hơn là trước tiên hãy nắm bắt khoảng trống nhỏ nhất: ví dụ: che lối vào cũ bằng một lớp bộ điều hợp, trước tiên cho phép chuỗi công cụ mới đứng bên ngoài thế giới cũ và nhìn rõ cấu trúc, sau đó từ từ di chuyển vào. Copilot rất thích hợp để xử lý loại công việc cơ khí này: điền hàng nhập, di chuyển cấu hình, trích xuất các đoạn lặp lại và tạo bộ khung thử nghiệm tạm thời. Hãy để mô hình làm những việc này, hiệu quả quả thực rất cao; nhưng mọi người vẫn quyết định xem có nên cắt đường may này hay không và giữ nguyên hành vi nào sau khi cắt.

Bạn cũng dễ bị đánh lừa bởi vẻ bề ngoài khi thử nghiệm. Vượt qua bài kiểm tra cũ không có nghĩa là hiện đại hóa an toàn, nó chỉ có nghĩa là những hành vi lịch sử nhất định vẫn chưa bị phá bỏ. Việc kiểm tra nhiều dự án cũ giống như những bức ảnh chụp nhanh hành vi hơn là các đặc tả ngữ nghĩa kinh doanh. Màu xanh lá cây chỉ là màu xanh lá cây và không thể hiểu trực tiếp là “hiểu hệ thống”. Một trong những hành động quan trọng nhất trong quá trình chuyển đổi là thêm các ranh giới thử nghiệm mới, hẹp hơn vào từng vết mổ nhỏ, để thử nghiệm dần dần thay đổi từ “di sản lịch sử” sang “ràng buộc hiện tại”. Copilot có thể giúp phá vỡ các xác nhận cũ, hoàn thiện các mẫu và triển khai các bản thử nghiệm trùng lặp. Tuy nhiên, ngữ nghĩa nào cần được duy trì trong thử nghiệm và mô hình không thể đưa ra quyết định cho hệ thống.

Trong quá trình hiện đại hóa khảo cổ học, sự phân công lao động đáng tin cậy nhất thực ra rất đơn giản: môi trường và khúc gỗ chịu trách nhiệm xác định sự thật, Phi công phụ chịu trách nhiệm di chuyển gạch và dịch thuật, còn con người chịu trách nhiệm quyết định lịch sử nào nên giữ lại và lịch sử nào nên cắt bỏ. Một khi một mô hình được sắp xếp để giải thích quá khứ của hệ thống, nó thường đưa ra những phỏng đoán thuyết phục hơn là bằng chứng; đặt nó trở lại vị trí quản lý bằng chứng và tổ chức máy móc, nó trở thành một trợ lý thực sự hữu ích hơn.