Phân loại nợ kỹ thuật (2018)

 (technology.riotgames.com)
3 điểm bởi GN⁺ 2024-10-01 | 1 bình luận | Chia sẻ qua WhatsApp

Phân loại nợ kỹ thuật

Giới thiệu

  • Bill "LtRandolph" Clark là quản lý kỹ thuật của đội Champions trong LoL và rất quan tâm đến nợ kỹ thuật.
  • Nợ kỹ thuật được định nghĩa là mã hoặc dữ liệu gây ra chi phí cho các lập trình viên trong tương lai.
  • Bài viết này giới thiệu các loại nợ kỹ thuật khác nhau mà Riot đã trải nghiệm và mô hình mà họ sử dụng nội bộ.

Ma trận

Để đánh giá nợ kỹ thuật, bài viết sử dụng ba trục chính: mức độ ảnh hưởng, chi phí sửa chữa, và tính lây lan.

Mức độ ảnh hưởng

  • Ảnh hưởng mà nợ kỹ thuật gây ra cho người chơi và lập trình viên.
  • Bao gồm lỗi, tính năng bị thiếu, hành vi ngoài dự kiến, v.v.

Chi phí sửa chữa

  • Thời gian và rủi ro cần thiết để sửa nợ kỹ thuật.
  • Những lỗi đơn giản có thể sửa trong vài phút, nhưng các vấn đề đã ăn sâu có thể mất vài tuần hoặc vài tháng.

Tính lây lan

  • Mức độ mà nợ kỹ thuật có thể lan rộng.
  • Ảnh hưởng đến tương tác với các hệ thống khác, việc sao chép dữ liệu, và triển khai tính năng mới.

Các loại nợ

Nợ cục bộ

  • Vấn đề chỉ phát sinh bên trong hệ thống và không ảnh hưởng ra bên ngoài.
  • Ví dụ: Cataclysm của Jarvan.
Ma trận Cataclysm
  • Mức độ ảnh hưởng: 1 / 5
  • Chi phí sửa chữa: 2 / 5
  • Tính lây lan: 1 / 5

Nợ MacGyver

  • Khi hai hệ thống xung đột được kết hợp với nhau bằng một giải pháp tạm bợ.
  • Ví dụ: std::string của C++ và lớp AString của Riot.
Ma trận std::string vs AString
  • Mức độ ảnh hưởng: 2 / 5
  • Chi phí sửa chữa: 3 / 5
  • Tính lây lan: -2 / 5

Nợ nền tảng

  • Khi những giả định nằm sâu trong hệ thống ảnh hưởng đến toàn bộ hệ thống.
  • Ví dụ: việc sử dụng ngôn ngữ script lua trong LoL.
Ma trận BlockBuilder Lua
  • Mức độ ảnh hưởng: 4 / 5
  • Chi phí sửa chữa: 4 / 5
  • Tính lây lan: 4 / 5

Nợ dữ liệu

  • Khi quá nhiều nội dung được chất chồng lên trên các loại nợ kỹ thuật khác, khiến việc sửa chữa trở nên khó khăn và rủi ro.
  • Ví dụ: lỗi tên tham số trong ngôn ngữ script BlockBuilder.
Ma trận lỗi tên tham số
  • Mức độ ảnh hưởng: 2 / 5
  • Chi phí sửa chữa: 2 / 5
  • Tính lây lan: 4 / 5

Tóm tắt

  • Khi đánh giá nợ kỹ thuật, cần xem xét mức độ ảnh hưởng, chi phí sửa chữa, và tính lây lan.
  • Tính lây lan cho thấy khả năng nợ kỹ thuật lan rộng; nếu bỏ qua, nó có thể trở thành vấn đề lớn.
  • Nợ kỹ thuật có thể được phân loại thành bốn nhóm: nợ cục bộ, nợ MacGyver, nợ nền tảng, và nợ dữ liệu.

Tóm tắt của GN⁺

  • Bài viết này giúp các lập trình viên đưa ra quyết định tốt hơn bằng cách giải thích các loại nợ kỹ thuật và cách đánh giá chúng.
  • Bài viết nhấn mạnh tính lây lan của nợ kỹ thuật, qua đó nhấn mạnh tầm quan trọng của việc giải quyết vấn đề từ sớm.
  • Các dự án khác có chức năng tương tự gồm Dota 2 và Overwatch.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-10-01
Ý kiến trên Hacker News

  • Giao diện là một trong những yếu tố quan trọng nhất trong thiết kế và cần được cân nhắc cẩn thận

    • Một giao diện đẹp có thể dễ dàng được cải thiện nếu có thời gian, nhưng điều ngược lại thì hiếm hơn

  • Nợ của nhà sáng lập là khoản nợ do các nhà sáng lập tạo ra để cung cấp công nghệ nhanh và tốt

    • Các văn kiện thành lập của nhiều quốc gia cũng thuộc nhóm này

  • Thật ngạc nhiên khi bài viết này được viết bởi một engineering manager

    • Có xu hướng không có manager được thăng tiến từ nội bộ mà tuyển từ bên ngoài

  • Có thảo luận về cách phân loại technical debt

  • Đây là một bài viết xuất sắc từ góc nhìn kỹ thuật

    • "Danh pháp" có thể là cách diễn đạt phù hợp hơn
    • Mỗi ví dụ đều rất gợi suy nghĩ

  • Dùng "Contagion" để giải thích technical debt

    • Đó là một cách giải thích tuyệt vời

  • Technical debt được định nghĩa là mã hoặc dữ liệu mà các nhà phát triển tương lai sẽ phải trả chi phí

    • Khi tạo ra khoản nợ, cần cân bằng giữa nhu cầu tức thời và chi phí trong tương lai
    • Có một sự ác cảm gần như bệnh lý đối với nợ

  • Tôi sẽ không gọi "nợ cục bộ" là technical debt trong tình huống thông thường

    • Ở đâu đó sẽ luôn có sự lộn xộn, và việc đóng gói nó lại là điều phổ biến

  • Có kinh nghiệm làm việc ở nhiều startup

    • Các nhà sáng lập thường nhầm lẫn giữa ý tưởng, thứ đã thực sự được triển khai và phần đang hoạt động

  • Đôi khi người ta cố ý gánh technical debt để đổi lấy lợi ích ngắn hạn

    • Lợi ích này cũng nên được xem xét như một trục khác