“Đang chạy — đừng đụng vào” — nó là gì, bản chất của nguyên tắc và rủi ro

Nguyên tắc “đang chạy — đừng đụng vào” là gì?

“Đang chạy — đừng đụng vào” — là một quy tắc thực nghiệm cảnh báo lập trình viên không thay đổi mã đang chạy mà không có lý do chính đáng. Nguyên tắc dựa trên thống kê đơn giản: phần lớn các lỗi được tạo ra trong quá trình sửa đổi mã hiện có.

Nguyên tắc không phải là một giáo điều — nó là một phương pháp heuristics giúp đưa ra quyết định trong điều kiện không chắc chắn. Cơ sở mã càng phức tạp và rắc rối, thì khả năng một thay đổi “vô hại” làm hỏng thứ gì đó mà không ai ngờ tới càng cao.

Theo một nghiên cứu của Microsoft Corporation (2024), khoảng 60% tất cả các sự cố nghiêm trọng trong sản xuất có liên quan đến các thay đổi mã gần đây được thực hiện với ý định tốt nhưng không được kiểm tra đầy đủ trong điều kiện tải thực tế.

Lịch sử và nguồn gốc của nguyên tắc

Câu nói “Nếu nó không hỏng, đừng sửa nó” bắt nguồn từ văn hóa kỹ thuật Mỹ giữa thế kỷ 20. Việc sử dụng được ghi lại sớm nhất được cho là của Bert Lance (1977), người làm việc trong Ủy ban Tài chính Thượng viện Hoa Kỳ và phản đối việc quản lý quá mức.

Trong lập trình, nguyên tắc này đến từ kỹ thuật phần cứng, nơi việc thay thế một chip đang hoạt động bằng chip mới có thể dẫn đến những hậu quả không lường trước. Trong bối cảnh phần mềm, nguyên tắc này trở nên đặc biệt phổ biến khi độ phức tạp của hệ thống phần mềm tăng lên và mã legacy xuất hiện.

Thú vị là, trong lập trình, nguyên tắc này cũng có mặt trái — “chạy tốt, nhưng tốt nhất là đừng đụng vào” thường trở thành cái cớ để tránh tái cấu trúc, dẫn đến tích tụ nợ kỹ thuật nghiêm trọng. Theo công ty tư vấn Thoughtworks (2023), khoảng 40% các dự án gặp vấn đề nghiêm trọng do thái độ bảo thủ quá mức đối với các thay đổi.

Khi nào áp dụng nguyên tắc

Nguyên tắc “đang chạy — đừng đụng vào” đặc biệt phù hợp trong những tình huống mà chi phí của một lỗi vượt quá lợi ích tiềm năng của các thay đổi.

Dự án legacy không có kiểm thử

Trong mã legacy không được bao phủ bởi kiểm thử, bất kỳ thay đổi nào cũng là trò chơi cò quay Nga. Nếu một lập trình viên không thể xác minh rằng thay đổi không làm hỏng các module lân cận, chiến lược tốt nhất là không đụng vào mã đang chạy. Ngoại lệ chỉ là các lỗi nghiêm trọng hoặc yêu cầu bảo mật.

Hệ thống quan trọng

Trong các hệ thống mà thời gian chết là không thể chấp nhận hoặc chi phí của một lỗi là rất lớn — phần mềm y tế, hệ thống hàng không, giao dịch tài chính — nguyên tắc “đang chạy — đừng đụng vào” là tiêu chuẩn thực tế. Mọi thay đổi đều phải trải qua phê duyệt và kiểm thử nhiều giai đoạn.

Thời hạn gấp

Nếu bản phát hành là ngày mai và mã đang chạy — đừng cố gắng cải thiện kiến trúc của nó. Chỉ thay đổi những gì ảnh hưởng trực tiếp đến chức năng của bản phát hành. Hoãn việc tái cấu trúc sang sprint tiếp theo (nhưng đừng quên nó).

Rủi ro khi tuân theo nguyên tắc

Tuân theo mù quáng nguyên tắc “đang chạy — đừng đụng vào” mang lại rủi ro không kém gì việc tái cấu trúc vô tận. Hãy xem xét những nguy hiểm chính.

Tích tụ nợ kỹ thuật

Nếu mọi lập trình viên tuân theo nguyên tắc này, cơ sở mã nhanh chóng biến thành một “bánh nhiều lớp” gồm các giải pháp lỗi thời, các bản vá tạm thời và các thuật toán không tối ưu. Không sớm thì muộn, nợ kỹ thuật trở nên không thể chịu được — bất kỳ thay đổi nào cũng cần hàng tuần phân tích.

Cơ hội tối ưu hóa bỏ lỡ

Đôi khi, một thay đổi có vẻ rủi ro lại thực sự cải thiện đáng kể hiệu suất hoặc bảo mật. Nguyên tắc “đang chạy — đừng đụng vào” không nên chặn các thay đổi mang lại lợi ích đo lường được — giảm chi phí máy chủ, tăng tốc tải trang, cải thiện bảo mật.

Mất năng lực

Khi một nhóm không đụng vào các phần mã nhất định trong nhiều năm, họ mất hiểu biết về cách chúng hoạt động. Lập trình viên chủ chốt rời đi — và mã trở thành legacy không có khả năng hỗ trợ. Nguyên tắc nên được áp dụng có tính đến khả năng bảo trì lâu dài của dự án.

Trung dung vàng: tái cấu trúc không cuồng tín

Chiến lược tối ưu không phải là tuân theo nguyên tắc mù quáng, mà là áp dụng nó một cách có ý thức, tính đến bối cảnh. Tái cấu trúc là cần thiết, nhưng phải được thực hiện một cách an toàn.

Quy tắc hướng đạo sinh

Quy tắc hướng đạo sinh trong lập trình: “Hãy để lại mã sạch hơn lúc bạn tìm thấy nó.” Nếu một lập trình viên thực hiện thay đổi trong một module, họ nên cải thiện cấu trúc của nó, nhưng trong giới hạn hợp lý. Không viết lại mọi thứ từ đầu, nhưng ít nhất hãy đổi tên các biến khó đọc và thêm chú thích.

Tái cấu trúc dưới sự bảo vệ của kiểm thử

Kiểm thử là cách duy nhất để áp dụng an toàn nguyên tắc “đang chạy — đừng đụng vào”. Nếu mã được bao phủ bởi kiểm thử, bất kỳ việc tái cấu trúc nào cũng trở nên có thể dự đoán được: lập trình viên thay đổi mã, chạy kiểm thử và xem liệu có gì hỏng không. Không có kiểm thử — đừng đụng vào. Có kiểm thử — tái cấu trúc một cách tự tin.

// Ví dụ: tái cấu trúc an toàn dưới bao phủ kiểm thử
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Mã cũ nhưng hoạt động
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Kiểm thử bảo vệ khỏi hồi quy
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Ví dụ này minh họa cách tiếp cận đúng: đầu tiên là kiểm thử, sau đó là tái cấu trúc. Nếu kiểm thử thành công, thay đổi là an toàn. Nguyên tắc “đang chạy — đừng đụng vào” biến thành “chạy tốt dưới kiểm thử — tái cấu trúc mạnh dạn.”

Ví dụ thực tế

Hãy xem xét các kịch bản thực tế nơi nguyên tắc “đang chạy — đừng đụng vào” vừa là cứu cánh vừa là tai họa.

Trường hợp cứu cánh: vấn đề giống Y2K

Một lập trình viên phát hiện rằng mã xử lý ngày sử dụng định dạng DD/MM/YY thay vì YYYY. Mã đã hoạt động chính xác từ năm 2000 đến 2025. Mặc dù muốn “sửa” nó, anh ấy để mã như cũ, chỉ thêm một chú thích. Năm 2026, công ty đã cập nhật hệ thống và giải pháp mới xử lý chính xác các thế kỷ. Một thay đổi sớm sẽ chỉ phá vỡ logic đang hoạt động.

Trường hợp tai họa: mất dữ liệu do “cải tiến”

Một kỹ sư đã quyết định “cải tiến” mã nhập dữ liệu cũ nhưng đang hoạt động bằng cách thay thế nó bằng một thư viện hiện đại. Anh ta không tính đến việc thư viện cũ xử lý một trường hợp đặc biệt cụ thể không được ghi chép lại. Sau khi phát hành — mất dữ liệu hàng loạt. Nguyên tắc “đang chạy — đừng đụng vào” đã bị vi phạm, và chi phí của lỗi là hai tuần làm việc của nhóm để khôi phục.