Crutch trong lập trình — nó là gì, nguyên nhân và khi nào thì hợp lý

Crutch trong lập trình là gì

Crutch — giải pháp phần mềm hoạt động nhưng được làm một cách nhanh chóng: nó vá một vấn đề cụ thể nhưng không loại bỏ nguyên nhân của nó, không tuân theo kiến trúc dự án và có thể hỏng khi có thay đổi nhỏ trong môi trường. Phép ẩn dụ chính xác — giống như cái nạng thật, code như vậy giúp “đi” nhưng không chữa khỏi “chân”.

Các lập trình viên “chống đỡ bằng crutch” các lỗi, sự không tương thích phiên bản, đặc thù nền tảng và yêu cầu gấp rút của khách hàng. Một crutch điển hình — crutch-điều kiện: nếu iOS 15 thì thêm khoảng cách, nếu Huawei thì ẩn nút. Những kiểm tra như vậy nhân lên và biến code thành một “bánh nhiều lớp” từ các rẽ nhánh nền tảng và phiên bản.

Crutch có nhiều quy mô khác nhau: từ một dòng lệnh với điều kiện crutch đến cả một mô-đun lớp trung gian “sửa chữa” hành vi của thư viện. Điều quan trọng là hiểu rằng crutch không phải lúc nào cũng xấu: trong tay đúng, nó là công cụ giúp phát hành sản phẩm đúng hạn. Vấn đề bắt đầu khi crutch ở lại trong code mãi mãi.

Tại sao crutch xuất hiện: nguyên nhân và bối cảnh

Nguyên nhân chính của sự xuất hiện crutch — xung đột giữa giải pháp lý tưởng và các ràng buộc thực tế của dự án. Lập trình viên biết cách làm đúng, nhưng thời gian, tiền bạc hoặc giới hạn kỹ thuật không cho phép điều đó. Kết quả là một giải pháp thỏa hiệp “chỉ hoạt động”.

Hãy xem xét bốn nguyên nhân chính khiến lập trình viên cố tình dùng crutch. Hiểu những nguyên nhân này giúp coi crutch không phải là sai lầm, mà là công cụ thực dụng cần được quản lý.

Thời hạn chót

Nguyên nhân phổ biến nhất. Phát hành vào ngày mai, lỗi chỉ tái hiện trên một model cụ thể, sửa kiến trúc mất hai tuần. Crutch-điều kiện mất một giờ và vá vấn đề. Sau khi phát hành, đội hứa sẽ quay lại và viết lại đúng cách. “Không có gì tạm thời lâu dài hơn là vĩnh viễn, và không có gì vĩnh viễn tạm thời hơn” — chính là nói về những crutch như vậy.

Không tương thích phiên bản

Thư viện A yêu cầu Android 12, nhưng ứng dụng của bạn hỗ trợ Android 10. Giải pháp — viết lớp trung gian kiểm tra phiên bản OS và chọn đường thực thi. Đây là crutch, vì khi cập nhật thư viện, lớp trung gian sẽ phải viết lại. Nhưng lựa chọn thay thế — từ bỏ thư viện hoặc hỗ trợ thiết bị cũ — có thể còn tệ hơn.

// Crutch cho tương thích API 29
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Phụ thuộc bên thứ ba có lỗi

Thư viện mà dự án phụ thuộc chứa lỗi, nhưng việc cập nhật nó có thể mất hàng tuần (cần PR, code review, công bố). Thay vì chờ đợi, đội viết wrapper vá hành vi của thư viện ngay lúc chạy. Sau khi phiên bản sửa lỗi được phát hành, wrapper sẽ được xóa. Nếu không xóa — đó đã là vấn đề kiến trúc.

Hiểu biết không đầy đủ về hệ thống

Lập trình viên mới trong dự án legacy không hiểu tại sao code hoạt động như vậy. Thay vì tìm hiểu, anh ta thêm điều kiện mới lên trên điều kiện hiện có. Đây là loại crutch nguy hiểm nhất, vì tác giả không nhận thức rằng đó là crutch. Phương thuốc duy nhất — code review và lập trình cặp cho các thành viên mới của đội.

Khi nào crutch hợp lý: cách tiếp cận thực dụng

Không phải crutch nào cũng xấu. Trong phát triển thực tế, sự sạch sẽ tuyệt đối của code là không thể đạt được và thường không phù hợp. Cách tiếp cận thực dụng thừa nhận rằng các giải pháp tạm thời là một phần của quy trình, nhưng yêu cầu nhận thức, tài liệu hóa và lập kế hoạch loại bỏ chúng. Crutch hợp lý khi nó giải quyết vấn đề kinh doanh nhanh hơn giải pháp kiến trúc thuần túy.

Các tiêu chí của crutch hợp lý: nó vá một vấn đề cụ thể, có chủ sở hữu (ai chịu trách nhiệm xóa nó), và tồn tại kế hoạch tái cấu trúc. Nếu thiếu một trong ba điều kiện — crutch biến thành nợ kỹ thuật. Công cụ như TODO-comment với ticket trong tracker — cách tài liệu hóa tối thiểu.

Ví dụ về crutch hợp lý

Lỗi nghiêm trọng trong nhánh phát hành cần được vá trước khi triển khai vào ngày mai. Giải pháp thuần túy yêu cầu tái cấu trúc kiến trúc và mất hai tuần. Crutch — thêm kiểm tra nil và gửi bản sửa dưới dạng hotfix. Điều kiện hợp lý: trong tracker đã tạo ticket tái cấu trúc, người chịu trách nhiệm được chỉ định, crutch được đánh dấu bằng comment. Sau hai tuần, đội quay lại nhiệm vụ.

// TODO: IT-1234 — xóa crutch này sau khi tái cấu trúc AuthService
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Cách phân biệt crutch tạm thời với vấn đề kiến trúc

Ranh giới giữa crutch có ý thức và vấn đề kiến trúc (nợ kỹ thuật) đi qua hai tham số: nhận thức về quyết định và sự tồn tại của kế hoạch loại bỏ nó. Crutch luôn là giải pháp tạm thời với tuổi thọ đã biết. Nợ kỹ thuật — hậu quả của nhiều crutch bị bỏ quên.

Khi nào crutch trở thành vấn đề

Tình hình xấu đi khi số lượng crutch vượt quá khối lượng tới hạn. Mỗi crutch mới làm tăng “tính dễ vỡ” của hệ thống: thay đổi ở một nơi làm hỏng nơi khác. Cuối cùng, phát triển chậm lại, lỗi nhân lên, và lập trình viên mới không thể hiểu code mà không có sự giúp đỡ của tác giả. Lúc này crutch không còn là giải pháp tạm thời và trở thành vấn đề kiến trúc.

Dấu hiệu khủng hoảng crutch

Nếu trong code gặp năm kiểm tra lồng nhau về phiên bản OS, nhà sản xuất thiết bị và sự tồn tại của thư viện cụ thể — đây không phải crutch, mà là vấn đề kiến trúc. Nếu thêm một bản sửa gây ra ba hồi quy trong các mô-đun liên quan — crutch không còn cục bộ nữa. Nếu code review thường xuyên bị từ chối vì “một crutch nữa” — đã đến lúc lên kế hoạch tái cấu trúc.

• Một crutch lặp lại ở ba nơi trở lên — đã đến lúc tạo giải pháp thống nhất
• Crutch tồn tại hơn ba sprint không có kế hoạch loại bỏ — đó đã là nợ kỹ thuật
• Lập trình viên mới không thể hiểu tại sao code hoạt động như vậy — crutch không được tài liệu hóa
• Xóa crutch gây ra phản ứng dây chuyền lỗi — sự phụ thuộc vào crutch đã trở thành kiến trúc

Tái cấu trúc crutch: chiến lược và thực hành

Tái cấu trúc crutch — quá trình thay thế các giải pháp tạm thời bằng các giải pháp đúng về mặt kiến trúc. Điều này đòi hỏi thời gian, vì vậy cần chiến lược ưu tiên: không phải tất cả crutch đều cần loại bỏ ngay lập tức. Chiến lược tốt — đánh giá mỗi crutch theo hai tham số: tần suất thay đổi trong khu vực code đó và ảnh hưởng đến người dùng.

Chiến lược ưu tiên

Ưu tiên cao — crutch trong các mô-đun thường thay đổi (logic kinh doanh, UI đa năng), làm chậm phát triển và gây hồi quy. Ưu tiên trung bình — crutch trong các mô-đun ít thay đổi nhưng có ảnh hưởng tiềm năng đến người dùng (xử lý thanh toán, xác thực). Ưu tiên thấp — crutch trong code legacy hoạt động ổn định và không có kế hoạch sửa đổi.

Quy trình từng bước loại bỏ

Bước 1: kiểm kê — tìm tất cả TODO và FIXME liên quan đến crutch. Bước 2: đánh giá — xác định cái nào vẫn còn phù hợp. Bước 3: lập kế hoạch — lên lịch tái cấu trúc crutch trong sprint, bắt đầu từ ưu tiên cao. Bước 4: thay thế — triển khai giải pháp thuần túy, xóa crutch và TODO-comment của nó. Bước 5: xác minh — đảm bảo test pass và không có hồi quy.

# Tìm tất cả TODO-crutch trong dự án
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Ngăn chặn crutch mới

Cách tốt nhất để chống lại crutch — không tạo ra chúng khi không cần thiết. Trước khi viết crutch, hãy tự hỏi ba câu: Có thể làm giải pháp thuần túy trong thời gian hợp lý không? Có lựa chọn thay thế không phải là crutch không? Đội có thời gian quay lại và viết lại không? Nếu ít nhất một câu trả lời là “không” — hãy suy nghĩ lại trước khi “chống đỡ” code.