Technical Debt

Bằng chứng (4)

• 3Simon Willison·6/9/2026research
  Vì sao các dự án viết lại toàn bộ thường thất bại

  Simon Willison cho rằng việc viết lại một hệ thống cũ từ đầu hiếm khi giải quyết gọn gàng nợ kỹ thuật, vì hệ thống cũ vẫn phải tiếp tục thay đổi trong khi hệ thống mới chưa hoàn thành. Ông khuyên nên củng cố hệ thống hiện tại bằng kiểm thử tự động và refactor có mục tiêu, đồng thời xem migration là cách bền vững hơn để xử lý nợ kỹ thuật.

• 1Simon Willison·6/9/2026research
  Trích dẫn về độ phức tạp của phần mềm

  Bài viết này là một trích dẫn ngắn của Zach Kehs, được Simon Willison chia sẻ, cho rằng phần mềm có thể tiếp tục xấu đi mà không có giới hạn vật lý cứng như công trình xây dựng. Trích dẫn nhấn mạnh việc các lớp trừu tượng hóa chồng chất và suy giảm hiệu năng có thể tích tụ dần trong mã nguồn theo thời gian.

• 3Hacker News·5/9/2026research
  Vì sao mã phần mềm vẫn có thể tiếp tục tệ hơn

  Bài viết lập luận rằng những ẩn dụ như “con tàu đang chìm” dễ gây hiểu lầm khi nói về hệ thống phần mềm, vì mã nguồn không có một “đáy” tự nhiên để sự xuống cấp dừng lại. Thay vào đó, phần mềm có thể tích tụ vô hạn các lớp phức tạp, độ gián tiếp và suy giảm hiệu năng, trong khi các tổ chức thường khó đơn giản hóa hệ thống cũ do mất mát tri thức, chi phí phối hợp và động lực nội bộ. Bài viết lấy ví dụ một hệ thống xử lý đơn hàng cũ để cho thấy nợ kỹ thuật có thể kéo dài và phình to theo thời gian.

• 4Martin Fowler·2/4/2026research
  LLM, nợ nhận thức và kiểm chứng trong phát triển phần mềm

  Martin Fowler giới thiệu một cách nhìn chia hệ thống thành ba lớp sức khỏe: nợ kỹ thuật, nợ nhận thức và nợ ý định, cho rằng mỗi loại đều kìm hãm một khía cạnh khác nhau của việc tiến hóa phần mềm. Ông cũng đề cập nghiên cứu xem AI như “Hệ thống 3” trong nhận thức, đồng thời nhận định rằng khi tác nhân viết mã làm chi phí tạo code giảm xuống, kiểm chứng sẽ trở thành công việc có giá trị và khó hơn.