Có nghiên cứu khoa học nào được thực hiện trên TDD sử dụng tổng chi phí sở hữu cho một sản phẩm làm phép đo không?

Khi tôi đang đọc bản tóm tắt của công việc trước đây ở Dogsa T, Batic D. Hiệu quả của phát triển dựa trên thử nghiệm: một nghiên cứu trường hợp công nghiệp. Tạp chí chất lượng phần mềm. 2011; 19 (4): 643-661. tôi nhận ra rằng các phép đo được sử dụng trong rất nhiều nghiên cứu xung quanh TDD dựa trên những thứ như dòng mã, khiếm khuyết và thời gian dành cho phát triển.

Có nghiên cứu nào ngoài đó tập trung vào tổng chi phí sở hữu cho các sản phẩm đã được phát triển bằng TDD so với phát triển truyền thống hoặc thử nghiệm cuối cùng không?

Tôi đặc biệt quan tâm đến tổng chi phí mua lại và chi phí vận hành.

Có một số nghiên cứu về ý nghĩa và lợi ích của việc làm TDD, nhưng kết quả là mâu thuẫn. Một số dự án (theo kinh nghiệm của tôi) có tỷ lệ lỗi và chi phí sở hữu thấp hơn do sử dụng TDD, vì chi phí thay đổi một tính năng giảm đáng kể. Một số người khác dừng lại để dừng lại.

Một số nghiên cứu ( đây là một - kiểm tra slide n50) cho thấy số lượng lỗi tăng lên với phạm vi bảo hiểm. Tôi giả định rằng phạm vi bảo hiểm lớn hơn ngụ ý TDD và số lỗi cao hơn có nghĩa là chi phí sở hữu cao hơn.

Theo quan điểm của tôi, không có số liệu hay thực hành nào có thể liên quan đến chất lượng tốt hơn hoặc chi phí sở hữu thấp hơn. Có sự kết hợp của các yếu tố có thể dẫn đến một số mối tương quan. Và những yếu tố thay đổi giữa các đội và dự án.

Tôi nghĩ rằng tất cả chúng ta đã nghe câu chuyện về các đội, mới bắt đầu thực hiện TDD, viết các phương pháp kiểm tra 100 dòng, (theo quan điểm của tôi) làm tăng chi phí sở hữu, vì việc cập nhật bài kiểm tra đó sẽ tốn kém.

Quy tắc thực dụng của tôi là những người quan tâm và ham học hỏi , làm việc trong một môi trường hỗ trợ họ và ý tưởng của họ có chất lượng và chi phí sở hữu tốt hơn.

Tôi không có nghiên cứu cụ thể nào nhưng tôi có thể nói với bạn từ kinh nghiệm cá nhân và từ kinh nghiệm của các nhà phát triển khác tôi biết rằng khi áp dụng đúng cho các dự án vừa và lớn hơn TDD sẽ giảm thời gian tiếp thị, giảm lỗi và lỗi và cải thiện chất lượng mã .

Đã nói rằng chúng không phải là viên đạn bạc, bạn có thể viết mã tốt mà không cần TDD không? có, bạn có thể viết mã xấu bằng TDD có không. Ngoài ra, tùy thuộc vào TDD dự án của bạn có thể làm tăng đáng kể chi phí sở hữu mã của bạn, một ví dụ điển hình là NASA, trong đó chi phí cho mỗi dòng mã là rất lớn, nhưng chi phí sở hữu không phải là trọng tâm, nó thiếu khiếm khuyết.

Khi được áp dụng đúng TDD sẽ tăng chi phí ban đầu và cơ sở mã của bạn, nhưng bạn nhận được lợi ích lâu dài của kiểm tra hồi quy, phát hiện lỗi sớm và thiết kế mã tốt hơn để giảm lỗi và chi phí kiểm tra và thời gian bảo trì, do đó giảm chi phí chung quyền sở hữu.