Có nghiên cứu thực nghiệm nào về ảnh hưởng của việc nhận xét mã nguồn đối với chất lượng phần mềm, khả năng bảo trì và năng suất của nhà phát triển không? [đóng cửa]


11

Tôi là một người ủng hộ bình luận về mã nguồn và tài liệu sản phẩm phần mềm. Đó là kinh nghiệm cá nhân và quan sát của tôi rằng làm việc với mã nguồn được nhận xét nghiêm ngặt đã giúp tôi theo những cách khác nhau khi tôi phải phát triển phần mềm hoặc bảo trì nó.

Tuy nhiên, có một trại khác nói rằng bình luận cuối cùng là vô giá trị hoặc giá trị của nó là nghi vấn. Nhiều người đề xuất mã hóa mà không bình luận cho rằng:

  • Nếu một đoạn mã được viết tốt, nó sẽ tự giải thích và do đó không cần bình luận
  • Nếu một đoạn mã không tự giải thích, thì hãy cấu trúc lại nó và làm cho nó tự giải thích để nó không cần bất kỳ bình luận nào
  • Bộ kiểm tra của bạn là tài liệu trực tiếp của bạn
  • Theo thời gian mã và nhận xét không đồng bộ và nó trở thành một nguồn đau đầu khác
  • Agile nói rằng mã làm việc quan trọng hơn đống tài liệu, vì vậy chúng ta có thể bỏ qua việc viết bình luận một cách an toàn

Đối với tôi đây chỉ là giáo điều. Một lần nữa, quan sát cá nhân của tôi là phần mềm được viết bởi các nhóm các nhà phát triển thông minh và có kinh nghiệm cuối cùng kết thúc với một số lượng đáng kể mã không tự giải thích được.

Một lần nữa, API Java, API ca cao, API Android, v.v. cho thấy rằng nếu bạn muốn viết và duy trì tài liệu chất lượng, điều đó là có thể.

Đã nói tất cả những điều này, các cuộc trò chuyện về ưu và nhược điểm của tài liệu và nhận xét về mã nguồn dựa trên niềm tin cá nhân thường không kết thúc tốt và dẫn đến không có kết luận thỏa mãn.

Vì vậy, tôi đang tìm kiếm các bài báo học thuật và nghiên cứu thực nghiệm về tác động của tài liệu phần mềm, đặc biệt là nhận xét mã nguồn, về chất lượng và khả năng bảo trì cũng như ảnh hưởng của nó đến năng suất của nhóm.

Bạn có vấp phải những bài báo như vậy không và kết quả của chúng là gì, nếu có?


2
Tôi nghĩ dù sao đây cũng là một câu hỏi thú vị, nhưng tôi không ngạc nhiên lắm khi nó có thể bị đóng cửa ở đây. Đó là lý do tại sao tôi cũng đăng bài này trên Quora.
Behrang Saeedzadeh

4
@gnat - Dường như với tôi rằng "Nghiên cứu nào đã được thực hiện trong khía cạnh này của lĩnh vực phát triển phần mềm?" là một câu hỏi khá khác so với các yêu cầu "vui lòng đưa cho tôi sách về một chủ đề" không được hoan nghênh.
Josh Kelley

1
Chỉ từ việc đọc tiêu đề: Không có nghiên cứu thực nghiệm về ảnh hưởng của bất cứ điều gì đến chất lượng. Nếu có, trang web này sẽ không tồn tại.
Euphoric

2
@Euphoric hai câu nói của bạn mâu thuẫn với nhau. Nếu chúng ta bỏ qua tài liệu 30 năm "điên", không có xung đột. Nhưng dù sao đi nữa, chúng ta không nên bỏ qua những phát hiện chỉ vì chúng đã cũ, nhưng đánh giá nghiêm túc cách chúng liên quan đến công việc hiện đại (như chúng ta cũng nên có kết quả mới).

3
@Euphoric Tôi muốn bạn đăng nó như một câu trả lời, vì vậy tôi có thể đánh giá thấp sự thiếu nghiên cứu của bạn trong khẳng định chăn của bạn. Có hàng tấn bài báo và nghiên cứu, theo kinh nghiệm và mặt khác, về ảnh hưởng của các kỹ thuật khác nhau đến chất lượng phần mềm. Bạn đã học gì về Kỹ thuật phần mềm chưa?
Andres F.

Câu trả lời:


9

Trong "Hiệu ứng của mô đun hóa và nhận xét về hiểu chương trình" (1981), Woodfield, Dunsmore và Shen đã phát hiện ra rằng "các chủ đề mà chương trình chứa các bình luận có thể trả lời nhiều câu hỏi hơn những người không có ý kiến."

Tuy nhiên, trong "Học một thước đo về khả năng đọc mã" (2010), Raymond PL Buse và Westley Weimer nhận thấy rằng các bình luận chỉ có ảnh hưởng hạn chế đến khả năng đọc và chất lượng:

Từ tóm tắt:

Chúng tôi xây dựng một thước đo khả năng đọc tự động và ... cho thấy rằng số liệu này tương quan mạnh mẽ với ba thước đo chất lượng phần mềm: thay đổi mã, báo cáo lỗi tự động và thông báo nhật ký lỗi ... hơn các dòng trống đơn giản để đánh giá địa phương về khả năng đọc.

Từ trang 12:

Chúng tôi thấy rằng các bình luận chỉ tương quan vừa phải với khái niệm về khả năng đọc của người chú thích của chúng tôi (sức mạnh tương đối 33%). Một kết luận có thể là trong khi các bình luận có thể tăng cường khả năng đọc, chúng thường được sử dụng trong các đoạn mã bắt đầu ít đọc hơn: bình luận và mã không thể đọc được cân bằng một cách hiệu quả. Hiệu ứng ròng sẽ xuất hiện là các bình luận không phải lúc nào cũng, trong bản thân chúng, cho thấy khả năng đọc cao hay thấp.

Hãy nhớ rằng những người đề xuất "mã hóa mà không bình luận" không nói rằng mã không có bình luận sẽ tốt hơn mã có bình luận. Họ cho rằng một kiểucụ thể không có nhận xét - một kiểu trích xuất mã thành các phương thức với các tên tự mô tả, một kiểu giới thiệu các biến giải thích , một biến có bộ kiểm thử tốt - tốt hơn mã không làm những điều đó Nhưng có ý kiến. Điều này có thể làm phức tạp khả năng ứng dụng của bất kỳ nghiên cứu nào đã được thực hiện.


1
Bài báo của Woodfield và cộng sự nói về một loạt các bình luận cụ thể, gần tương đương với cái được gọi là Javadoc: "Cụ thể, nghiên cứu này cố gắng xác định xem các bình luận ngắn, được chèn ngay trước một mô-đun logic, có thể giúp hiểu được bằng cách mô tả ngắn gọn chức năng của mô-đun logic và giúp xác định ranh giới của mô-đun logic. "

Tôi nên nói thêm vào lúc đó: điều đó không có nghĩa là nó không có giá trị, thực sự đó là một nghiên cứu thú vị và được xây dựng tốt. Tôi chỉ nghĩ rằng cần phải nói rằng họ không lấy về tất cả các bình luận.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.