Legacy trong phát triển ứng dụng — khái niệm, rủi ro và chiến lược

Legacy trong phát triển ứng dụng là gì

Legacy — mã hoặc hệ thống tiếp tục chạy trong sản xuất nhưng không còn đáp ứng các tiêu chuẩn chất lượng hiện đại. Legacy có thể được viết bằng ngôn ngữ lỗi thời (ví dụ, Objective-C thay vì Swift), sử dụng các thư viện không được hỗ trợ hoặc các mẫu kiến trúc từ lâu được coi là phản mẫu.

Đặc điểm chính của legacy là thiếu kiểm thử. Theo định nghĩa của Michael Feathers (2004), mã legacy là mã không có kiểm thử. Nếu không thể thay đổi hành vi một cách an toàn, hệ thống ở trạng thái legacy bất kể tuổi đời. Mã mới không có kiểm thử đơn vị là legacy từ ngày đầu tiên.

Legacy không nhất thiết là xấu. Một hệ thống được thiết kế tốt bằng Java 8 có thể đáng tin cậy và dễ hiểu hơn mã hỗn độn trong Kotlin với coroutines. Tuổi của mã không phải là chỉ số chất lượng — điều quan trọng là hệ thống có thể được thay đổi và mở rộng dễ dàng như thế nào.

Tại sao mã legacy là bình thường

Mọi hệ thống thành công đều trở thành legacy theo thời gian. Đây là một quá trình tự nhiên: công nghệ phát triển nhanh hơn mã có thể được viết lại. Một ứng dụng được viết 5 năm trước bằng Swift 2 là legacy ngày nay, mặc dù nó hiện đại tại thời điểm tạo ra.

Giá trị kinh doanh của legacy thường bị đánh giá thấp. Hệ thống hoạt động ổn định, xử lý giao dịch, lưu trữ dữ liệu — viết lại mang rủi ro. Theo Standish Group (2024), 35% dự án viết lại toàn bộ kết thúc thất bại. Về mặt kinh tế, không phải loại bỏ legacy mà là học cách làm việc với nó.

Các chiến lược tốt nhất là di chuyển dần dần, đóng gói mã cũ đằng sau các giao diện mới và kiểm thử tự động. Legacy chỉ trở thành vấn đề khi nó không còn có thể thay đổi với chi phí dự đoán được.

Dấu hiệu chính của hệ thống legacy

Thiếu kiểm thử tự động — chỉ số chính. Nếu sau khi thay đổi một dòng duy nhất, nhà phát triển không thể chạy kiểm thử và xác nhận không có gì hỏng — bạn đang đối mặt với legacy. Dấu hiệu bổ sung: quy trình triển khai mất hàng giờ và yêu cầu các bước thủ công.

Tài liệu không khớp với mã — một dấu hiệu khác. Sơ đồ kiến trúc đã lỗi thời, các chú thích mô tả hành vi đã thay đổi. Thời gian làm quen cho nhà phát triển mới vượt quá một tháng — dấu hiệu của độ phức tạp cao và khả năng bảo trì thấp.

Các dấu hiệu bổ sung: kiến trúc nguyên khối không có ranh giới rõ ràng, kiểm thử thủ công là phương pháp xác nhận chính, đường ống CI dài (hơn 30 phút), sử dụng thư viện không có phiên bản mới nhất và không thể cập nhật phụ thuộc mà không làm hỏng các mô-đun liên quan.

Hiện tượng mã dễ vỡ — thay đổi một chỗ làm hỏng ba chỗ khác. Đây là hậu quả của sự kết nối chặt chẽ, khi các mô-đun biết quá nhiều về nhau. Kết nối càng cao, hệ thống càng nhanh chóng chuyển sang hạng mục legacy.

Rủi ro khi làm việc với mã lỗi thời

Giảm tốc độ — rủi ro chính. Thêm một tính năng đơn giản cần hàng giờ nghiên cứu mã và hàng ngày kiểm thử. Theo Stripe (2024), các nhà phát triển dành 33% thời gian để khắc phục nợ kỹ thuật, liên quan trực tiếp đến sự hiện diện của các mô-đun legacy trong dự án.

Rò rỉ chuyên môn — tác giả của mã gốc rời công ty và tài liệu không đầy đủ. Các nhà phát triển mới sợ chạm vào các mô-đun không quen thuộc, dẫn đến hiệu ứng mã đông lạnh: mô-đun không phát triển nhưng tiếp tục hoạt động. Bus factor của các hệ thống này cực kỳ thấp.

Bảo mật — các thư viện lỗi thời chứa các lỗ hổng đã biết. Sử dụng OpenSSL 1.0.2 hoặc các phiên bản cũ của Jackson trong các dự án Java là con đường trực tiếp dẫn đến các sự cố bảo mật có thể khiến doanh nghiệp mất uy tín và khách hàng.

Mất động lực đội nhóm — làm việc với legacy mà không có chiến lược cải thiện làm giảm sự hài lòng của nhà phát triển. Đội nhóm không còn tự hào về sản phẩm, tỷ lệ nhân viên nghỉ việc tăng, làm chậm sự phát triển hệ thống hơn nữa.

Chiến lược tái cấu trúc legacy

Characterization tests — bước đầu tiên trước bất kỳ thay đổi nào đối với mã legacy. Chạy mã với dữ liệu đầu vào đã biết và ghi lại đầu ra dự kiến. Các kiểm thử này ghi lại hành vi hiện tại như một đặc tả. Golden master testing là một biến thể nơi đầu ra được so sánh với tệp tham chiếu.

Phân tích Seam — tìm các điểm có thể phá vỡ kết nối mà không thay đổi hành vi. Michael Feathers xác định một số loại seam: preprocessor seam, object seam, link seam. Object seam là phổ biến nhất: thay thế đối tượng thực bằng stub kiểm thử qua giao diện.

Sprout method và Sprout class — các kỹ thuật thêm mã mới bên cạnh mã cũ, không phải bên trong nó. Thay vì sửa đổi phương thức hiện có, hãy tạo phương thức mới với logic mong muốn và gọi nó từ phương thức cũ. Điều này giảm thiểu rủi ro làm hỏng mã đang hoạt động.

Ví dụ: thêm logging vào legacy

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 dòng mã legacy không nên chạm vào
        logPayment(payment) // phương thức sprout
    }
    def logPayment(payment) {
        // mã mới được thêm vào bên cạnh legacy
    }
}

Di chuyển sang nền tảng công nghệ hiện đại

Mẫu Strangler Fig — cách tiếp cận được khuyến nghị cho di chuyển legacy. Một mô-đun mới được tạo song song, lưu lượng truy cập dần dần được chuyển từ cũ sang mới. Mô-đun cũ tự nhiên chết khi không còn nhận được yêu cầu. Mẫu này giảm thiểu rủi ro và cho phép khôi phục nếu có sự cố.

Branch by Abstraction — kỹ thuật tạo lớp trừu tượng trên cả cài đặt cũ và mới. Mã client chuyển sang lớp trừu tượng và cài đặt cũ dần dần được thay thế. Ví dụ: thay thế lớp mạng từ AFNetworking sang Alamofire qua giao thức NetworkService thống nhất.

Di chuyển theo giai đoạn — chia quá trình chuyển đổi thành các bước nhỏ: đóng gói mô-đun cũ → viết kiểm thử → tạo mô-đun mới → chạy song song → xóa mô-đun cũ. Mỗi bước kết thúc với trạng thái hệ thống ổn định, cho phép triển khai bất cứ lúc nào.