Khái niệm, các loại và cách giải quyết nợ kỹ thuật

• Khái niệm nợ kỹ thuật
  • Chi phí ngầm của việc phải làm lại trong tương lai, phát sinh khi chọn một giải pháp dễ nhưng bị giới hạn thay vì chọn cách tiếp cận tốt hơn dù có thể mất nhiều thời gian hơn
  • Chi phí công việc bổ sung phát sinh khi chọn giải pháp nhanh nhất thay vì giải pháp hiệu quả nhất
• Các loại nợ kỹ thuật theo phân loại của kỹ sư phần mềm Martin Fowler
  • Nợ kỹ thuật thận trọng và có chủ đích (Prudent & Deliberate)
    • Đội ngũ biết mình đang gánh nợ, nhưng cân nhắc liệu “phần thưởng từ việc phát hành nhanh hơn có lớn hơn chi phí trả nợ hay không”
  • Nợ kỹ thuật liều lĩnh và có chủ đích (Reckless & Deliberate)
    • Kết quả của việc biết các thực hành thiết kế tốt và có thể thực hiện, nhưng không có thời gian để viết mã sạch nên quyết định làm theo kiểu “nhanh và bẩn”
  • Nợ kỹ thuật thận trọng nhưng không chủ đích (Prudent & Inadvertent)
    • Kết quả của việc đã phát triển phần mềm tốt và mã cũng sạch, nhưng chỉ sau một thời gian mới nhận ra “thiết kế lẽ ra phải như thế nào”
  • Nợ kỹ thuật liều lĩnh và không chủ đích (Reckless & Inadvertent)
    • Kết quả phát sinh do thiếu hiểu biết
• Cách giải quyết nợ kỹ thuật
  • Quản lý danh sách nợ kỹ thuật
    • Nhìn lại dự án để lập danh sách nợ kỹ thuật và chia sẻ trong nhóm
    • Mỗi khi phát sinh nợ kỹ thuật, ghi lại công việc cần thiết để xử lý khoản nợ đó cùng với mức độ nỗ lực và lịch trình dự kiến
    • Cả nhóm thảo luận có xử lý nợ kỹ thuật hay không, thời điểm xử lý và xây dựng phương án giải quyết
  • Phân biệt nợ kỹ thuật tốt và nợ kỹ thuật xấu
    • Việc phân loại như vậy giúp xác định mức độ ưu tiên cho vấn đề lớn nhất
  • Refactoring
    • Trong quá trình làm việc, sắp xếp lại những phần cần thiết và refactor dần từng chút một
    • Khi thực hiện refactor quy mô lớn, chia sẻ tình hình với nhóm và thông báo rủi ro cùng chi phí của nợ kỹ thuật
  • Viết mã kiểm thử
    • Mã càng phức tạp, phạm vi refactor càng lớn thì càng khó sửa mã một lần mà không phát sinh lỗi
    • Để ngăn tác dụng phụ, cần viết mã kiểm thử
  • Thiết lập và tuân thủ tiêu chuẩn chất lượng
    • Thiết lập tiêu chuẩn chất lượng để ngăn lập trình viên triển khai mã cẩu thả
  • Không thay đổi đột ngột quy định hoặc lịch trình
    • Nếu liên tục thay đổi các quy định liên quan đến nhà phát triển hoặc dời deadline, sẽ rất khó tránh nợ kỹ thuật
    • Cần cung cấp lịch trình, phương pháp luận và khối lượng công việc thực tế để có thể quản lý nợ kỹ thuật
• Nợ kỹ thuật có phải lúc nào cũng hoàn toàn xấu?
  • Trong cuốn sách của Chris Riccomini và Dmitriy Ryaboy, 『Phải đọc! Hướng dẫn onboarding cho lập trình viên: sự ra đời của một lập trình viên chuyên nghiệp hiểu về phần mềm bền vững và văn hóa cộng tác trơn tru』 có câu: “Nếu đó là khoản nợ đã được rèn luyện để đội ngũ có thể giải quyết về sau, thì có thể xem đó là ‘nợ tốt’”
  • Nhưng nợ kỹ thuật có thể gây ảnh hưởng tiêu cực đến doanh nghiệp nên cần được giải quyết
  • Điều này có thể biểu hiện thành bug và làm suy giảm trải nghiệm người dùng
  • Khi nợ kỹ thuật trở nên nghiêm trọng hơn, lập trình viên sẽ khó làm việc hơn trong codebase hiện có
  • Việc phải chia thời gian giữa phát triển tính năng mới và sửa tính năng cũ khiến vòng đời phát triển phần mềm chậm lại và thời điểm đưa sản phẩm ra thị trường bị trì hoãn