Mô hình hình học của bảo trì

Đang trên đường đi? Hãy nghe phiên bản được AI đọc to của bài viết này. James Shore cho rằng mỗi tháng viết mã sẽ dẫn đến 10 ngày bảo trì trong năm đầu tiên, sau đó là 5 ngày mỗi năm. Nếu giải thích một cách đơn giản, đây là một mô hình dựa trên ngưỡng cho bảo trì được gây ra, và nó thú vị vì nó đơn giản đến vậy. Nếu có thể chứng minh được rằng nó đúng sự thật, thì điều đó sẽ hữu ích. Lập luận mà Shore đưa ra về tác động của mã do robot tạo ra không phụ thuộc vào những con số cụ thể, vì vậy những con số của Shore đến từ một nguồn trí tuệ tập thể giả thuyền hơn là dữ liệu thực tế. Nhưng ở đây không cần bất kỳ giả thuyền nào. Chúng ta có một thứ gọi là git. Hãy nói chúng ta có một cách để gán nhãn cho mỗi lần commit là 'phát triển mới' hoặc 'bảo trì'. Sau đó chúng ta có thể đếm xem có bao nhiêu commit của mỗi loại trong một tháng. Bài viết này sẽ giả định rằng bảo trì cần thiết sẽ được thực hiện, và nếu bảo trì không được thực hiện, thì đó là vì nó không thực sự cần thiết từ góc độ của người dùng tổng thể. Tôi biết rằng nhiều người sẽ phản đối với giả định này vì bảo trì họ nghĩ là cần thiết mà không được thực hiện, nhưng hãy thử đặặt nghi ngờ sang một bên. Nếu bạn tiếp tục sử dụng phần mềm ngay cả khi thứ đó không được sửa chữa, thì thứ đó thực sự cần thiết đến mức nào để giữ bạn ở lại như một người dùng? Có thể tốt hơn, chúng ta có thể đếm được lượng độ phức tạp đã được xử lý trong một tháng. Trong phân tích này, tôi đang đếm kích thước tổng thể của commit, tức là số lần thêm cộng với số lần xóa, như lượng cố gắng đã đầu tư vào commit.