“Technical Debt” là gì? update năm 2022

Có một khái niệm rất hay mà trong những sách vở về tăng trưởng ứng dụng hay nhắc đến, gọi là “ technical debt ” – “ món nợ kĩ thuật ”. Khái niệm này chỉ đến hiện tượng kỳ lạ một ứng dụng hoàn toàn có thể được chuyển giao ( deliver ) tới người mua trong trạng thái còn bug ( do chưa được test kĩ hoặc cố tính che lấp đi để người mua không nhìn thấy ). Khi người mua dùng ứng dụng thì phát hiện ra lỗi đó, và họ nhu yếu “ tương hỗ kĩ thuật ” hoặc “ bảo dưỡng ” – khi đó đơn vị chức năng sản
xuất phải có nghĩa vụ và trách nhiệm thực thi những việc “ cực chẳng đã này ” : trả nợ kĩ thuật .

Nhìn từ góc độ kinh tế, “nợ kĩ thuật” là rất rủi ro và có thể rất tốn kém. Bug được phát hiện càng lâu sau khi phần mềm bắt đầu được làm ra thì càng đắt đỏ. Một bug được phát hiện bởi developer trong lúc lập trình có thể có chi phí (phải fix) bằng 1/100, thậm chí 1/10.000 so với bug được phát hiện ra lúc thành phẩm đã đến tay người dùng cuối ( lúc đó cũng phải fix, nhưng với chi phí lớn hơn nhiều lần: cử người ra fix lỗi, vá lỗ hổng, deploy lại, v.v – mà hầu như không được trả tiền thêm). Do vậy, để giảm thiểu rủi ro về món nợ này chỉ có một cách duy nhất: làm ra phần mềm chạy tốt, ngay từ đầu.

Nhìn từ góc độ kĩ thuật, “món nợ kĩ thuật” ám chỉ sự yếu kém trong kĩ năng chuyên môn (do yếu kém trong đảm bảo chất lượng) hoặc đạo đức  nghề nghiệp (do cố tình “che mắt” khách hàng các lỗi kĩ thuật), dẫn đến sản phẩm không đạt chất lượng lẽ ra nó vốn phải có. Đương nhiên, đơn vị sản xuất cũng phải trả món nợ này theo cách đắng cay nhất: tiền mất – tật mang ( vừa mất uy tín, vừa mất tiền).

Hiện nay nhiều quan điểm chất lượng ( hời hợt ) thường đổ dồn về phía người mua : người mua mà gật đầu ( acceptance ) thì tức là chất lượng cao. Sự thực không đơn thuần như vậy, bởi người mua thì thường không nhìn vào dòng lệnh, nên bản thân họ không chắc như đinh được 100 % về cái hoạt động giải trí bên ngoài ( external behavior ) của ứng dụng có thực sự là “ chất lượng ” hay không. Quan điểm chất lượng truyền thống cuội nguồn ( mang tính tiêu chuẩn ) thì cho rằng phải có cái tốt “ tự thân ” : ứng dụng được gọi là có chất lượng khi nó phải có những “ đặc tính ” tốt “ vốn có ” chứ không phải là do tại ai đó bên ngoài gọi nó là “ tốt ” hay không tốt. Cố nhiên, cái tốt đó phải hướng đến “ người mua ”, chứ không phải là cái tốt được vẽ ra từ trong đầu developer. Chỉ khi tất cả chúng ta gật đầu cái quan điểm sau ( tức quan điểm về đặc tính tốt vốn có ) thì mới thuận tiện gật đầu những ngân sách thiết yếu để góp vốn đầu tư cho chất lượng, và không gắn vào mẫu sản phẩm những “ món nợ kĩ thuật ”, những quả bom nổ chậm hoàn toàn có thể phát huy công dụng hủy hoại uy tín và túi tiền của đơn vị chức năng sản xuất ứng dụng .
Scrum và những chiêu thức agile khác thường nhấn mạnh vấn đề giá trị chất lượng bằng khái niệm “ built-in quality ” – tức là giá trị có sẵn, tự thân, do chính người sản xuất ( developer ) làm ra chứ không phải dựa trọn vẹn vào người ngoài ( QA, tester, người mua ). Trách nhiệm bảo vệ chất lượng là của chính người sản xuất ( developer ) chứ không phải ai khác. Đó cũng là cách mà agile Scrum giảm thiểu những “ món nợ kĩ thuật ” xuống mức thấp nhất hoàn toàn có thể. Các chính sách như TDD, BDD, ATDD, pair-programming sẽ không để những bug có thời cơ Open, vì ngay từ đầu, nó đã được developer chủ định “ phòng ngừa ” ( bug-prevention ) .

Source: https://intalents.co
Category: Hướng Nghiệp