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.
Last updated