💻
Tech notes
  • Các nguyên tắc trong kiến trúc phần mềm
  • Vòng đời phát triển phần mềm SDLC
  • 6 nguyên lý thiết kế microservices
  • MLOps Roadmap
  • SBOMs là gì?
  • Thuật thức hơi thở của Review Code
  • Tại sao code lại bốc mùi thối?
  • Corner testcase là gì?
  • So sánh mô hình Scrum và mô hình waterfall, Sprial
  • Quy trình release phiên bản phần mềm
  • 12 tuyên ngôn Agile
  • Conventional Commits
  • Chatgpt Prompt for coder
  • Quản trị dữ liệu
  • Nợ kỹ thuật
  • So sách Data-Centric và Model-Centric
  • Tracking Evaluation Measures
  • Mô hình Kano
  • Clean Code with C++ in cxview.ai
  • Các mức độ rủi ro về technical debt
  • Phiếu tự đánh giá cho hệ thống sản xuất học máy
  • Quản lý chất lượng trong ML
Powered by GitBook
On this page

Nợ kỹ thuật

Khi những deadline được đặt ra không hoàn toàn phù hợp với khối lượng thời gian cần bỏ ra để hoàn thành một công việc cụ thể. Các lập trình viên sẽ phải chấp nhận dùng những "giải pháp tạm thời" để cho ra sản phẩm "chạy được và ổn định" trong thời gian ngắn nhất và sau đó sẽ dành thời gian để cải tiến, nâng cấp thành những giải pháp hiệu quả, có thể tồn tại lâu dài hơn. Đây là cách mà nợ kĩ thuật "hình thành và tích lũy".

Phương án hạn chế:

  • Review code chéo giữa các thành viên

    • Các công cụ hỗ trợ review code: Review Board, Gerrit, Crucible

    • Tập trung vào các chức năng quan trọng nhất thay vì review toàn bộ mã nguồn

  • Thường xuyên refactor code

    • Khi phát hiện các lỗi kỹ thuật: Khi tìm thấy lỗi kỹ thuật trong mã nguồn, nên refactor code để khắc phục lỗi đó.

    • Khi thêm chức năng mới vào phần mềm: Khi thêm chức năng mới vào phần mềm, có thể refactor code để làm cho mã nguồn dễ đọc, dễ hiểu và dễ bảo trì hơn.

    • Khi sửa đổi yêu cầu: Khi sửa đổi yêu cầu của khách hàng, có thể refactor code để phù hợp với yêu cầu mới.

    • Khi mã nguồn quá phức tạp: Nếu mã nguồn quá phức tạp, có thể refactor code để giảm độ phức tạp của mã và cải thiện hiệu suất của phần mềm.

    • Khi thấy có thể tối ưu hóa mã nguồn: Nếu tìm thấy mã nguồn không tối ưu hoặc có thể cải thiện, có thể refactor code để tối ưu hoá mã nguồn.

    • Khi đọc lại mã nguồn thấy khó hiểu: Nếu đọc lại mã nguồn thấy khó hiểu hoặc không dễ đọc, có thể refactor code để làm cho mã nguồn dễ đọc và dễ hiểu hơn.

PreviousQuản trị dữ liệuNextSo sách Data-Centric và Model-Centric

Last updated 2 years ago