Hiện đại hóa mật mã cũ trước hết cần khảo cổ học

Điều khó nhất của code cũ không bao giờ là cú pháp cũ mà là lỗi thời. Một dự án chứa đầy build.xml, JDK cũ, khung thử nghiệm cũ và các phương pháp đóng gói cũ. Nhìn bề ngoài, nó trông giống như nhiều chồng hồ sơ, nhưng thực ra nó là các lớp giả định lịch sử xếp chồng lên nhau. Bản thân mã chỉ là lớp ngoài cùng. Điều thực sự cản trở việc phân phối thường là liệu những giả định này có còn ở đó hay không, liệu chúng có thể được tái tạo hay không và liệu hành vi cũ có bị mất đi sau khi thay đổi hay không.

Đây là lý do tại sao “khảo cổ học” đi trước “sự biến đổi”. Trước tiên hãy xem tệp xây dựng, sau đó là các phần phụ thuộc, sau đó là môi trường đang chạy, sau đó là các bài kiểm tra. Thứ tự không thể đảo ngược. Build.xml vẫn còn đó, nhưng pom.xml không tồn tại. Những tín hiệu như vậy đủ để cho thấy dự án đang sống trong kỷ nguyên Ant; liệu mã có thể được biên dịch hay không, liệu các bài kiểm tra có thể chạy được hay không và liệu sản phẩm có thể được xây dựng lại hay không là bằng chứng đầu tiên. Phần hữu ích nhất của mô hình ở đây không phải là viết ngay mã mới cho mã cũ mà là xác định những bằng chứng này từ một đống mảnh vỡ.

Môi trường cũng phải được ghim đầu tiên. Mã cũ thường đi kèm với các JVM cũ, vùng chứa cũ và các giả định kiến ​​trúc cũ. Ném nó trực tiếp vào các máy ngày nay, đặc biệt là trong môi trường đa kiến ​​trúc và rất dễ tạo ra tiếng ồn mới khi xảy ra sự cố: mã vốn đã bị hỏng hay chính việc mô phỏng, sao chép và chuỗi công cụ đang gây ra sự cố? Nếu bạn thậm chí không thể đạt được “cùng một mã có thể được sao chép ổn định trong cùng một môi trường” ở giai đoạn này, thì mọi hành động hiện đại hóa tiếp theo sẽ chỉ là phỏng đoán.

Giá trị của AI trong bước này rất rõ ràng: nó có thể hỗ trợ dịch cấp độ ký tự và cấp độ cấu trúc. Chuyển đổi Ant sang Gradle, chuyển đổi các tập lệnh xây dựng cũ thành dạng hiện có thể bảo trì được, di chuyển một loạt XML lặp đi lặp lại và bản soạn sẵn sang một vị trí rõ ràng hơn đều là những ứng cử viên phù hợp để chuyển sang mô hình. Nó nhanh chóng, sẵn sàng thử đi thử lại và không quá tầm thường. Nhưng nó không phù hợp để làm trọng tài. Những cảnh báo nào có thể được giữ lại trước, những bài kiểm tra nào thực sự đang nói dối, những mô-đun nào nên bị cắt bỏ trước và những lớp nào chỉ nên được đóng gói và điều chỉnh. Cuối cùng vẫn phải do con người quyết định.

Kiểm tra là cách dễ nhất để đánh lừa mọi người. Việc vượt qua các bài kiểm tra trong dự án cũ không có nghĩa là hệ thống đã được hiểu, nó chỉ có nghĩa là một số hành vi cũ chỉ được bao bọc trong môi trường hiện tại. Cảm giác “hoàn toàn xanh” đó rất nguy hiểm vì nó thường che giấu một vấn đề lớn hơn: những gì thử nghiệm xác minh là chi tiết triển khai của một thời đại nhất định, chứ không phải ngữ nghĩa kinh doanh cần được bảo tồn ngay bây giờ. Nếu thực sự muốn cải cách, điều đầu tiên cần làm là đưa những bài kiểm tra này ra khỏi “cảm giác an toàn mang tính trang trí” và đánh giá lại những gì chúng đang bảo vệ.

Do đó, cách ổn định nhất đối với loại dự án này thường không phải là viết lại nó trong một lần mà trước tiên hãy tạo một khoảng thời gian để khắc phục môi trường cũ, hành vi cũ và sự phụ thuộc cũ, sau đó loại bỏ nó theo những vết nứt hẹp nhất. Đầu tiên, làm cho hệ thống có thể tái tạo, sau đó giao công việc lặp đi lặp lại cho AI để dịch, sau đó bóc tách ranh giới theo từng lớp. Nếu không trật tự, mô hình sẽ đẩy nhanh dự án cũ và đẩy nó vào tình trạng hỗn loạn sâu sắc hơn; nếu đúng thứ tự, mô hình sẽ giống như một trợ lý khảo cổ thực sự hữu ích, chịu trách nhiệm di chuyển gạch, lau bụi và so sánh bằng chứng, giải phóng con người khỏi công việc bẩn thỉu và để họ tự phán xét.