Technical debt – Có nợ ắt phải trả mà chẳng dev nào muốn trả cả

#1
3 Likes
#2

Nice topic!
Cơ mà tớ có một số điểm muốn bổ sung thêm nha :smile: Đây là 2 xu của tớ:

  • “Giải pháp tạm thời” (a.k.a Workaround solution) là các giải pháp quick and dirty, tức xử lý được vấn đề nhanh, nhưng không tốt trong tương lai lâu dài.
    Đây là nguyên nhân số 1 của technical debt. Motivation của nó là thiếu kỷ luật (ai cũng muốn xong việc nhanh), hoặc pressure (deadline), đã được liệt kê ở bài viết :smile:
  • Vấn đề của technical debt là ở việc code có khả năng maintain rất kém.
    Với các workaround solution được đưa ra chằng chịt mà không có tổ chức, điều này dẫn tới việc code hoặc rất khó hiểu, hoặc chồng chéo lên nhau khiến cho việc thêm/sửa tính năng có thể làm hỏng các tính năng sẵn có.
    Về mặt tính năng, chương trình vẫn chạy được, nhưng chương trình có khả năng mở rộng rất kém, cost để cài đặt tính năng mới cao => đây là nợ :smile:
  • Vì vấn đề chủ yếu của technical debt là maintainability, nên technical debt thực sự là khoản nợ nếu nó nằm ở các đoạn code thường xuyên có yêu cầu thêm tính năng mới.
    Nếu phần nào của chương trình không cần mở rộng, việc thanh toán debt đó không có ý nghĩa.
  • Các biểu hiện của technical debt là các anti-pattern. Nếu cậu thấy code của bạn có triệu chứng ở trên, cậu cần cân nhắc tái cấu trúc code (refactor).
  • Tái cấu trúc code (refactor) là cách tốt nhất để thanh toán technical debt. Tuy nhiên, vì refactor cũng là engineering cost, nên nếu cậu cần refactor để trả nợ, cậu cần cân nhắc refactor chỉ những chỗ có tiềm năng phải sửa nhiều thôi :smile:
    Và, refactor với mục đích thanh toán nợ luôn phải đi kèm với test (unit test, integration test, automation test, etc), để ít nhất đảm bảo tính năng kỳ vọng không bị thay đổi trong quá trình refactor.

Hi vọng 2 xu trên của tớ có ích cho các bạn :smile:

5 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?