Vì sao "đập đi xây lại" là quyết định rủi ro nhất trong vòng đời phần mềm?
Viết lại toàn bộ hệ thống nghe có vẻ là cách "làm sạch" mọi vấn đề, nhưng thực tế đây là loại dự án có tỷ lệ trễ tiến độ và vượt ngân sách cao nhất. Lý do: hệ thống cũ, dù xấu xí, thường chứa hàng trăm quy tắc nghiệp vụ ẩn (business logic ngầm) được tích lũy qua nhiều năm mà không ai còn nhớ hết — viết lại nghĩa là phải tái khám phá toàn bộ những quy tắc đó, đồng thời vẫn phải vận hành hệ thống cũ song song.
3 điều kiện để cân nhắc viết lại toàn bộ
| Điều kiện | Dấu hiệu nhận biết |
|---|---|
| Chi phí sửa > chi phí xây mới | Mỗi tính năng nhỏ mất nhiều tuần để thêm vào, và thường làm hỏng tính năng khác (hiệu ứng domino) |
| Công nghệ nền tảng đã lỗi thời | Không tuyển được lập trình viên biết công nghệ cũ, hoặc framework/ngôn ngữ đã ngừng được hỗ trợ (End-of-life) |
| Kiến trúc không thể mở rộng | Đã thử tối ưu (cache, nâng cấp server, tối ưu query) nhưng hệ thống vẫn không chịu tải được nhu cầu thực tế |
Chỉ nên viết lại toàn bộ khi cả 3 điều kiện trên xảy ra đồng thời. Nếu chỉ gặp 1-2 điều kiện, phương án nâng cấp từng phần thường là lựa chọn an toàn và tiết kiệm hơn.
Phương án thay thế: Nâng cấp/tái cấu trúc có kiểm soát
Thay vì viết lại "big bang", chiến lược an toàn hơn là tách dần từng phần hệ thống cũ (Strangler Pattern): xây module mới song song, chuyển traffic từng phần sang module mới, và chỉ tắt phần cũ khi phần mới đã được kiểm chứng ổn định trong thực tế. Cách này giữ hệ thống luôn ở trạng thái vận hành được trong suốt quá trình chuyển đổi, thay vì "đóng băng" tính năng mới trong nhiều tháng để chờ viết lại xong.
Khi nào viết lại lại là lựa chọn đúng?
- Hệ thống được xây trên nền tảng đã bị nhà cung cấp khai tử hoàn toàn (không còn bản vá bảo mật)
- Không còn ai — kể cả đội cũ — hiểu được logic nghiệp vụ trong code, và tài liệu không tồn tại
- Chi phí duy trì hàng năm đã vượt quá chi phí ước tính để xây lại toàn bộ trong 12-18 tháng
Rủi ro cần lường trước nếu quyết định viết lại
- Bỏ sót business logic ẩn trong hệ thống cũ dẫn đến hệ thống mới thiếu tính năng khi go-live
- Chi phí vận hành song song 2 hệ thống trong giai đoạn chuyển tiếp
- Đội ngũ vừa phải bảo trì hệ thống cũ vừa xây hệ thống mới, dễ quá tải nếu không tách riêng nhân sự