Một khoảng trống đáng ngạc nhiên tồn tại trong nghiên cứu phát triển phần mềm: không ai biết các lập trình viên thực sự dành bao nhiều thời gian để viết code phát hiện và xử lý lỗi so với việc xây dựng các tính năng cốt lõi. Điều này được phát hiện khi một nhà nghiên cứu đang làm việc trên các công cụ chịu lỗi tìm kiếm dữ liệu để hỗ trợ cho các tuyên bố về năng suất của họ, chỉ để phát hiện ra rằng các phép đo đáng tin cậy đơn giản là không tồn tại.
Con số cụ thể duy nhất có sẵn đến từ một cuốn sách năm 1995 của Tiến sĩ Flaviu Cristian , người ước tính rằng việc xử lý lỗi thường chiếm hơn hai phần ba code trong các hệ thống sản xuất. Gần ba thập kỷ sau, điều này vẫn là điểm tham chiếu định lượng duy nhất trong một ngành công nghiệp đã trở nên ngày càng phức tạp và phân tán.
Các Thống Kê Chính Từ Nghiên Cứu Hiện Có:
- Xử lý lỗi chiếm hơn hai phần ba mã nguồn trong các hệ thống sản xuất (nghiên cứu năm 1995 của Tiến sĩ Flaviu Cristian )
- Các nhà phát triển dành khoảng 11% thời gian của họ để gỡ lỗi và sửa bug trung bình
- Một số ngày có thể dành tới 32% thời gian cho các tác vụ gỡ lỗi
- Các hoạt động kiểm thử có thể tiêu tốn tới 16% thời gian của nhà phát triển
- Các công ty tuyên bố thiệt hại 2 nghìn tỷ USD do lỗi phần mềm trong năm 2020
Các Công Ty Tránh Đo Lường Những Gì Họ Không Muốn Tài Trợ
Việc thiếu dữ liệu không hoàn toàn là ngẫu nhiên. Nhiều công ty cố ý tránh theo dõi thời gian dành cho việc tăng cường bảo mật vì nó không đóng góp trực tiếp vào phát triển tính năng hoặc tạo ra doanh thu. Điều này tạo ra một điểm mù nơi công việc thiết yếu nhưng không hào nhoáng bị bỏ qua và không được đánh giá đúng mức.
Một số tổ chức có theo dõi thời gian sửa lỗi cho mục đích báo cáo tài chính, phân biệt giữa chi phí hoạt động (sửa lỗi) và chi phí vốn (xây dựng tính năng). Tuy nhiên, cách tiếp cận dựa trên kế toán này chỉ nắm bắt được việc gỡ lỗi phản ứng, không phải việc xử lý lỗi chủ động xảy ra trong quá trình phát triển ban đầu.
Thách Thức Đo Lường Vượt Ra Ngoài Việc Theo Dõi Đơn Giản
Ngay cả khi các công ty muốn đo lường các nỗ lực tăng cường bảo mật, nhiệm vụ này tỏ ra phức tạp một cách đáng ngạc nhiên. Công việc xử lý lỗi thường xảy ra đồng thời với các hoạt động phát triển khác. Một lập trình viên có thể kích hoạt một bài kiểm tra tải, làm việc trên các tính năng khác trong khi nó chạy, sau đó quay lại phân tích kết quả và sửa các vấn đề. Quy trình làm việc xen kẽ này khiến việc theo dõi thời gian chính xác trở nên khó khăn mà không thêm chi phí đáng kể.
Vấn đề mở rộng ra ngoài chỉ là logistics đo lường. Các cách tiếp cận lập trình khác nhau về cơ bản thay đổi cách thời gian xử lý lỗi được phân phối. Với các kiểu kết quả, các lập trình viên phải xem xét các tình huống thất bại ở mỗi bước, dẫn đến việc phát triển ban đầu lâu hơn nhưng code mạnh mẽ hơn. Với các hệ thống dựa trên ngoại lệ, các lập trình viên có thể tập trung vào đường dẫn hạnh phúc ban đầu, sau đó xử lý lỗi khi chúng xuất hiện trong quá trình kiểm tra.
Các Phương Pháp Xử Lý Lỗi Khác Nhau:
- Result Types: Yêu cầu xem xét khả năng thất bại ở mỗi bước, quá trình phát triển ban đầu dài hơn nhưng mã nguồn mạnh mẽ hơn
- Exception-Based: Tập trung vào luồng chính trước, xử lý lỗi khi chúng xuất hiện trong quá trình kiểm thử
- Các Yếu Tố Đánh Đổi: Chi phí của thất bại, độ khó trong bảo trì tương lai, tính dễ dàng trong việc triển khai các bản sửa lỗi
Ngành Công Nghiệp Ưu Tiên Tốc Độ Hơn Khả Năng Phục Hồi
Động lực thị trường hiện tại rất ủng hộ việc phát triển tính năng nhanh chóng hơn là tăng cường phần mềm. Trong môi trường được thúc đẩy bởi vốn đầu tư mạo hiểm, các công ty thường chọn mở rộng cơ sở hạ tầng thay vì tối ưu hóa code, thêm các cơ chế thử lại đơn giản thay vì triển khai khả năng chịu lỗi thích hợp, và dựa vào bug bounties thay vì đầu tư vào bảo mật từ đầu.
Thời gian dành cho việc tăng cường phần mềm luôn bằng không hoặc rất gần với con số đó trừ khi công ty biến việc tăng cường đó thành điểm bán hàng của sản phẩm họ tạo ra.
Cách tiếp cận này tạo ra nợ kỹ thuật trở nên tốn kém để giải quyết sau này. Khi các vấn đề thực sự xuất hiện trong sản xuất, chi phí sửa chữa chúng vượt xa những gì việc tăng cường chủ động đã yêu cầu. Tuy nhiên, những người đưa ra các quyết định ngắn hạn này hiếm khi phải chịu trách nhiệm về hậu quả lâu dài.
Nghiên Cứu Tập Trung Vào Các Vấn Đề Học Thuật Trong Khi Bỏ Qua Các Câu Hỏi Thực Tế
Sự vắng mặt của các chỉ số ngành cơ bản làm nổi bật một vấn đề rộng lớn hơn trong nghiên cứu kỹ thuật phần mềm. Trong khi các nhà nghiên cứu ngày càng áp dụng các mô hình ngôn ngữ lớn cho các vấn đề nhân tạo và tuyên bố cải tiến gia tăng so với các đường cơ sở tùy ý, các câu hỏi cơ bản về cách các lập trình viên thực sự dành thời gian của họ vẫn chưa được trả lời.
Khoảng trống kiến thức này có hậu quả thực tế. Không có dữ liệu đáng tin cậy về chi phí xử lý lỗi, không thể đánh giá đúng các công cụ tuyên bố cải thiện năng suất của lập trình viên bằng cách giảm gánh nặng này. Các công ty không thể đưa ra quyết định sáng suốt về việc đầu tư vào cơ sở hạ tầng chịu lỗi, và ngành công nghiệp tiếp tục hoạt động dựa trên các giả định thay vì bằng chứng.
Tình hình này cho thấy cách một ngành công nghiệp được xây dựng trên dữ liệu và đo lường có những điểm mù đáng ngạc nhiên về các thực hành của chính nó. Cho đến khi những khoảng trống này được giải quyết, phát triển phần mềm sẽ tiếp tục được hướng dẫn bởi trực giác và áp lực thị trường hơn là bởi sự hiểu biết vững chắc về nơi thời gian và nỗ lực thực sự được dành.
Tham khảo: Time Spent on Hardening