Mã nguồn tồi tệ có thể tệ đến mức nào?

Ngày 6 tháng 9 năm 2026

[Phản hồi một bình luận về việc "đập đi xây lại" khi nợ kỹ thuật (technical debt) trở nên quá tải]

Theo kinh nghiệm của tôi, rất hiếm khi cách đó mang lại hiệu quả.

Bạn tuyên bố hệ thống cũ đã chìm sâu trong nợ kỹ thuật và không thể cứu vãn. Bạn thành lập một đội ngũ để viết lại từ đầu. Công việc bắt đầu.

Trong khi đó, hệ thống cũ vẫn là một mục tiêu di động: nó đang vận hành hoạt động kinh doanh cốt lõi, nên các thay đổi vẫn là cần thiết. Các lập trình viên làm việc với nó biết rằng hệ thống này sắp bị thay thế bởi cái mới, nên họ chẳng có động lực nào để làm hơn mức tối thiểu cần thiết nhằm thêm các tính năng mới. Nợ kỹ thuật cứ thế tiếp tục chồng chất.

Trong khi đó, đội ngũ làm việc với hệ thống mới lại đầy tham vọng và có lẽ hơi ngây thơ. Họ khởi đầu với tốc độ rất nhanh - dù sao thì đó cũng là một dự án greenfield - nhưng theo thời gian, rõ ràng là không ai hiểu hết hành vi và phạm vi của thứ mà họ đang thay thế. Suy cho cùng, nếu nó đã được tài liệu hóa và kiểm thử tốt thì đâu cần phải thay thế làm gì...

Sau nhiều tháng (hoặc thậm chí nhiều năm) không mang lại giá trị, áp lực "phải ra mắt" bắt đầu đè nặng, vì vậy hệ thống mới được tung ra để xử lý một phần nhỏ những gì hệ thống cũ từng làm - hoặc thường là cho một tính năng mới nào đó vốn quá khó để xây dựng trên hệ thống cũ đã không còn được bảo trì.

... và thế là bây giờ bạn có HAI hệ thống đang chạy thực tế (production) - hệ thống cũ kỹ, ọp ẹp mà chẳng ai muốn đụng vào, và một hệ thống mới chỉ xử lý được vài tính năng, với 80% là mã nguồn không hoạt động, vốn được dự định để thay thế hệ thống cũ trong tương lai.

Nếu thực sự may mắn, công ty sẽ không mất kiên nhẫn với hệ thống mới và cho phép công việc tiếp tục. Càng mất nhiều thời gian, và hệ thống cũ càng trụ vững trong môi trường production, thì rủi ro "thay đổi ưu tiên" càng cao, dẫn đến việc dự án thay thế hoàn toàn bị bỏ dở, để lại cho bạn hai hệ thống thay vì chỉ một như trước đây.

Bài viết hay nhất mà tôi từng đọc về cách hoàn thành quy trình này một cách có trách nhiệm là "Migrations: the sole scalable fix to tech debt" của Will Larson.

Nếu gặp phải tình huống tương tự trong tương lai, lời khuyên chân thành của tôi là hãy củng cố hệ thống cũ bằng càng nhiều kiểm thử tự động (automated testing) càng tốt, sau đó xem liệu các đợt tái cấu trúc (refactor) có mục tiêu có thể đưa nó về hình thái mong muốn hay không. Linh cảm của tôi là trong nhiều trường hợp, cách đó sẽ có cơ hội thành công cao hơn nhiều so với sức hấp dẫn đầy mê hoặc của việc thay thế bằng một dự án greenfield.