Điều gì xảy ra trong cuộc họp đánh giá mã?

Giới thiệu

Đánh giá mã ngang hàng đương đại là một quy trình nhẹ và không chính thức, trong đó các nhà phát triển (một. k. a. , những người đánh giá) đánh giá chất lượng của một bộ thay đổi mã mới được đề xuất, sử dụng một công cụ phần mềm chuyên dụng (Baum et al. )

Mặc dù đã áp dụng thực tế đáng kể việc xem xét mã (Rigby và Bird ), kiến ​​thức về tác động của nó—và cách đo lường chúng—vẫn còn hạn chế. Ví dụ, làm thế nào để đánh giá định lượng các lợi ích như chuyển giao kiến ​​thức giữa các nhà phát triển? . g. , Bacchelli và Bird ; . ) đã tìm thấy sự không phù hợp mạnh mẽ giữa những gì nhà phát triển và người quản lý nghĩ sẽ thu được từ việc xem xét mã (i. e. , phát hiện sớm các lỗi quan trọng) so với. những gì họ thực sự có được (tôi. e. , phát hiện rất ít lỗi, cục bộ, mức độ thấp)

Sự không phù hợp này không có gì đáng ngạc nhiên. Đánh giá hiệu quả của quy trình xem xét mã là một nhiệm vụ phức tạp và các công cụ đánh giá hiện tại cung cấp thông tin cơ bản, nhiều nhất là. Tuy nhiên, một số nghiên cứu công nghệ phần mềm thực nghiệm (e. g. , Kemerer và Paulk ; . ; . ; . ; . ; . ) đã quản lý để đưa ra các phương pháp có thể đánh giá các khía cạnh nhất định về tác động của việc xem xét mã và đã cung cấp thông tin có giá trị cho các nhà nghiên cứu về chủ đề này

Đặc biệt, ba nghiên cứu (Mäntylä và Lassenius ; Bacchelli và Bird ; Beller et al. ) đã xem xét quy trình xem xét mã từ một góc nhìn mới để điều tra các thay đổi về đánh giá. những thay đổi đối với mã được triển khai tại thời điểm xem xét (Hình. hiển thị một ví dụ về những thay đổi do đánh giá này)

Quả sung. 1

Ví dụ về những thay đổi do đánh giá mã gây ra trong JGit. Chẳng hạn, tại dòng 193, người đánh giá yêu cầu thay thế con số kỳ diệu “200” bằng một biến có tên có ý nghĩa. (https. //git. nhật thực. org/r/c/jgit/jgit/+/111364/20. 21/tổ chức. nhật thực. jgit. lfs/src/org/eclipse/jgit/lfs/LfsPrePushHook. Java)

Hình ảnh kích thước đầy đủ

Theo quan điểm này, những nghiên cứu này có thể (1) xác định rằng hầu hết các đánh giá mã không ảnh hưởng đến các chức năng của mã nguồn (Mäntylä và Lassenius ; Bacchelli và Bird ; Beller et al. ), (2) tìm ra sự không phù hợp đã nói ở trên giữa kỳ vọng và kết quả trong quá trình xem xét mã (Bacchelli và Bird), và (3) đưa ra một số tác động khác, trước đây không được ghi chép, của việc xem xét mã (Bacchelli và Bird). Ý tưởng chính đằng sau quan điểm này là một cách tiếp cận đánh giá quá trình xem xét mã bằng cách phân loại các loại thay đổi xem xét. Cách tiếp cận này trả lời các câu hỏi như. “Hầu hết các thay đổi đánh giá có sửa chữa các lỗi chức năng hoặc cải thiện các khía cạnh khác của mã không?”

Hai lợi thế quan trọng của việc nghiên cứu các thay đổi đánh giá là. (1) Nó xác định chính xác tác động tức thời của việc xem xét mã đối với mã và (2) nó không bị ảnh hưởng bởi các yếu tố gây nhiễu bên ngoài (e. g. , xu hướng thay đổi của tạo tác hoặc điều chỉnh trong quá trình phát triển) ảnh hưởng đến các số liệu dài hạn khác, chẳng hạn như xu hướng lỗi (McIntosh et al. )

Trong những năm gần đây, các nhà nghiên cứu tập trung vào việc tạo ra các công cụ tận dụng dữ liệu từ các hoạt động phát triển phần mềm (Ball et al. ; . ; . ). Cụ thể, các nhà nghiên cứu tại Microsoft đã phát triển một công cụ, CodeFlow Analytics (CFA), để thu thập và hiển thị cho các nhà phát triển thông tin về quy trình xem xét mã (Bird et al. ). CFA được tạo ra để đáp ứng yêu cầu của các nhóm phát triển nhằm dễ dàng phân tích và giám sát dữ liệu đánh giá mã của họ. chim và cộng sự. đã báo cáo cách CFA (1) cho phép thành công các nhóm phát triển tại Microsoft tự giám sát và cải thiện quy trình của họ và (2) có sẵn dữ liệu đánh giá mã đã khuyến khích nghiên cứu thêm để cải thiện quy trình đánh giá mã

Dựa trên sự chào đón tốt đẹp mà CFA nhận được, chúng tôi tin rằng việc tích hợp thông tin về các thay đổi trong quá trình đánh giá trong một công cụ tương tự có thể là bước tự nhiên tiếp theo để cho phép các nhóm phát triển hiểu rõ hơn về quy trình đánh giá mã của họ. Thông tin này có thể thúc đẩy nhóm phản ánh về các phương pháp đánh giá mã mà họ có tại chỗ. Chẳng hạn, nếu phần lớn các thay đổi là tài liệu thì những thay đổi này không thể được nắm bắt sớm hơn trong giai đoạn phát triển (e. g. , sử dụng các công cụ phân tích tĩnh hoặc cải thiện các nguyên tắc về phong cách của dự án). Điều này có thể cho phép các nhà phát triển phân bổ nhiều thời gian hơn để tìm kiếm các lỗi chức năng, điều quan trọng cho sự thành công của dự án

Tuy nhiên, việc áp dụng phương pháp này để giúp các nhà phát triển đánh giá quá trình xem xét của họ hiện đang bị hạn chế bởi hai yếu tố. Đầu tiên, các thay đổi do đánh giá gây ra phải được phân loại thủ công. Khía cạnh này tác động rõ ràng đến khả năng mở rộng của phương pháp, vì nó không thể dễ dàng được áp dụng rộng rãi. Thứ hai, mục tiêu của nỗ lực như vậy trong việc phân loại các thay đổi đánh giá chủ yếu là cộng đồng nghiên cứu và vẫn chưa rõ liệu đầu ra của nó có ý nghĩa như thế nào đối với các học viên

Trong bài báo này, chúng tôi trình bày một cuộc điều tra thực nghiệm gồm hai bước mà chúng tôi đã tiến hành để giải quyết những hạn chế này. Đầu tiên, chúng tôi điều tra xem liệu các thay đổi trong bài đánh giá có thể được phân loại tự động hay không bằng cách sử dụng phương pháp học máy được giám sát; . Cuối cùng, (1) chúng tôi phân loại thủ công 1.504 thay đổi đánh giá bằng cách sử dụng Beller et al. phân loại của (Beller et al. ); . ) cũng như thông tin chi tiết thu được khi xây dựng tập dữ liệu; . Kết quả của chúng tôi cho thấy rằng giải pháp được đánh giá phân loại các thay đổi mã với AUC-ROC vượt quá 0. 91. Phát hiện này cung cấp bằng chứng cho thấy máy học có thể được sử dụng hiệu quả để phân loại các thay đổi do đánh giá gây ra

Trong phần thứ hai của cuộc điều tra, chúng tôi tập trung vào việc thu thập phản hồi từ các nhà phát triển. Mục tiêu của chúng tôi là gấp đôi. Phân tích nhận thức của nhà phát triển liên quan đến việc phân loại các thay đổi của bài đánh giá nhằm hỗ trợ các hoạt động đánh giá cũng như đánh giá cách tiếp cận của chúng tôi trong một tình huống thực tế. Để đạt được mục đích này, (1) chúng tôi đã phỏng vấn 12 nhà phát triển có kinh nghiệm đánh giá mã và (2) chúng tôi đã gửi các báo cáo được tạo bằng cách tiếp cận của mình tới 20 dự án nguồn mở, nhận phản hồi từ 17 nhà phát triển. Các học viên đã đánh giá tích cực tính mới của thông tin về các thay đổi trong quá trình xem xét và đưa ra dấu hiệu ban đầu về tính hữu ích tiềm năng của thông tin này, đặc biệt đối với các nhà quản lý dự án quan tâm đến việc cải thiện quy trình xem xét mã

Bối cảnh và công việc liên quan

Chủ đề kiểm tra mã (Fagan ) đã được khám phá phần lớn trong quá khứ (Baum et al. ; . ) và, trong thập kỷ qua, cả cộng đồng nghiên cứu và những người thực hành đã chuyển sang khái niệm thực tế hơn về đánh giá mã hiện đại (Bacchelli và Bird). Về mặt này, các nhà nghiên cứu đã nghiên cứu các phương pháp và kỹ thuật để cung cấp hỗ trợ cho các nhà phát triển trong quá trình xem xét mã. Chẳng hạn, các nhà nghiên cứu đã nghĩ ra các giải pháp tự động để xác định những người đánh giá thích hợp cho một thay đổi mã mới (Ouni et al. ; . ; . ; . ), cũng như điều tra cả hai yếu tố làm cho quy trình hiệu quả hơn/kém hơn (Baum et al. ; . ; Bosu and Carver ; Kononenko et al. ; . ; . ; . ; . ) và ảnh hưởng thực sự của việc xem xét mã đối với chất lượng phần mềm thu được (Abelein và Paech ; Porter et al. ; . ; . ; . ; . ; . ; . )

Trong bối cảnh công việc của chúng tôi, chúng tôi chủ yếu quan tâm đến các thay đổi do xem xét lại (hoặc đơn giản là xem xét các thay đổi). Đây là những thay đổi mà mã trải qua do quá trình xem xét. e. g. , do nhận xét của người đánh giá (như trong Hình. ). Tuy nhiên, các thay đổi đối với mã cũng có thể được kích hoạt bởi các yếu tố khác. e. g. , một hành động tự phát từ tác giả mã hoặc các cuộc thảo luận không chính thức giữa các nhà phát triển. Trong bài báo này, mục tiêu chính của chúng tôi là khắc phục những hạn chế hiện tại để phân loại các thay đổi khi xem xét và đánh giá cách dữ liệu này có thể được sử dụng để hỗ trợ các nhà phát triển trong quá trình xem xét mã. Vì lý do này, trong phần này, chúng tôi tập trung thảo luận về các bài báo trước đây đã đối mặt với vấn đề phân loại các thay đổi đánh giá. Khảo sát tư liệu, chúng tôi thấy có ba tác phẩm chính

Đầu tiên, Bacchelli và Bird () đã phân tích quy trình xem xét mã tại Microsoft , tiết lộ một số mục tiêu bị đánh giá thấp và . trong số đó, họ chỉ ra rằng việc chuyển giao kiến ​​thức và nhận thức về các giải pháp thiết kế giữa các thành viên trong nhóm là những khía cạnh chính của việc xem xét mã hiện đại. Bacchelli và Bird () cũng nhấn mạnh rằng thách thức chính đối với các học viên khi thực hiện đánh giá mã là hiểu các thay đổi mã mới được cam kết. Phát hiện này thúc đẩy công việc của chúng tôi, vì nó cho thấy nhu cầu về các giải pháp có thể giúp phân loại và hiển thị cho người đánh giá những thay đổi nào đã được thực hiện.

Các giấy tờ khác nhằm mô tả những lỗi nào có thể được xác định trong quá trình xem xét mã. Theo hướng này, Mäntylä và Lassenius () là những người đầu tiên khám phá bằng thực nghiệm các loại lỗi được phát hiện trong các buổi xem xét mã cũng như sự phân bố của chúng trong cả bối cảnh công nghiệp và học viện. Để đạt được mục tiêu này, các tác giả đã đánh giá kết quả của hơn 100 phiên đánh giá mã và xác định phân loại các thay đổi mã. Phát hiện chính của họ báo cáo rằng 75% đánh giá được kiểm tra xác định các lỗi không ảnh hưởng đến hành vi bên ngoài của mã nguồn

Một bước nữa hướng tới hướng nghiên cứu này đã được thực hiện bởi Beller et al. (), người đã khám phá thêm những thay đổi nào được thực hiện trong đánh giá mã của các hệ thống nguồn mở, với mục đích điều tra những lợi ích thực sự do đánh giá mã hiện đại mang lại là gì. Họ đã xem xét hơn 1.400 thay đổi mã, gắn nhãn thủ công bằng cách sử dụng phân loại của Mäntylä và Lassenius (), bất cứ khi nào có thể. Kết quả là, họ đã đưa ra một phân loại cập nhật về các thay đổi mã được thực hiện trong quá trình xem xét mã, được hiển thị trong Hình.  

Quả sung. 2

Phân loại học (Beller et al. ) cho các thay đổi do đánh giá gây ra với danh mục/loại của chúng

Hình ảnh kích thước đầy đủ

Phân loại các thay đổi đánh giá

Phân loại của Beller et al. trình bày hai loại chính, cụ thể là (1) Các thay đổi về khả năng phát triển, có liên quan đến tất cả các sửa đổi không ảnh hưởng đến các chức năng được triển khai trong mã nguồn (e. g. , các tài liệu nhắm mục tiêu và tái cấu trúc) và (2) Thay đổi chức năng, là những thay đổi làm thay đổi cấu trúc của mã, do đó ảnh hưởng đến hoạt động bên trong của chương trình. Hai loại chính này sau đó đã được tinh chỉnh để báo cáo các loại thay đổi chức năng và khả năng tiến hóa cụ thể. Mô tả về từng loại thay đổi, cùng với ví dụ từ tình huống trong thế giới thực, có sẵn trong Phần và. Hơn nữa, mỗi loại có thể được chia thành các loại phụ. Có thể tìm thấy hai bảng mô tả đầy đủ về các loại thay đổi và các loại phụ tương ứng trong gói sao chép của chúng tôi

Công việc của chúng tôi được lấy cảm hứng rõ ràng từ bài báo của Beller et al. () và nhằm mục đích nghiên cứu sâu hơn giá trị của những phát hiện của họ. Chúng tôi điều tra một kỹ thuật để khắc phục những hạn chế về khả năng mở rộng của phương pháp phân loại của họ và cùng với các nhà phát triển đánh giá giá trị của thông tin đó khi xem xét các thay đổi

thay đổi khả năng tiến hóa

Các thay đổi về khả năng phát triển có thể được định nghĩa là các thay đổi về khả năng bảo trì, do đó, không có tác động đến các chức năng của hệ thống. Dựa trên phân loại của Beller et al. (), chúng có thể được chia thành năm loại

Thay đổi văn bản liên quan đến việc sử dụng thông tin văn bản trong mã. Đặc biệt, chúng tác động đến các thông báo ghi nhật ký, thêm hoặc cập nhật nhận xét hoặc đổi tên các biến để phù hợp hơn với môi trường (Hình. và )

Được hỗ trợ bởi các thay đổi ngôn ngữ tác động đến các tính năng dành riêng cho ngôn ngữ lập trình được sử dụng để truyền tải thông tin. e. g. , việc sử dụng từ khóa final hoặc tĩnh trong Java

Thay đổi biểu diễn trực quan có liên quan đến phong cách của mã. e. g. , chúng liên quan đến việc sử dụng sai cách thụt đầu dòng trong mã hoặc sự hiện diện của các dòng và khoảng trắng mới không cần thiết

Thay đổi tổ chức liên quan đến việc sắp xếp lại mã. Chẳng hạn, một thay đổi về tổ chức có thể loại bỏ các phần mã không sử dụng hoặc di chuyển một phương thức sang một lớp khác để cải thiện cấu trúc của dự án

Các thay đổi về cách tiếp cận giải pháp sẽ sửa đổi cách triển khai chức năng của hệ thống mà không sửa đổi chính chức năng đó. e. g. , việc loại bỏ các số ma thuật có lợi cho các hằng số được xác định trước (Hình. , , , , , , , và )

Quả sung. 3

Ví dụ về Thay đổi văn bản, trong đó một nhận xét được diễn đạt lại để thống nhất với các nhận xét tương tự. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn

Hình ảnh kích thước đầy đủ

Quả sung. 4

Ví dụ về Hỗ trợ do thay đổi ngôn ngữ, trong đó lớp mở rộng FtsServerOverloadExcpetion đã được thay đổi từ CouchbaseException thành TemporaryFailureException. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn http. //xem xét lại. đế đi văng. org/c/couchbase-java-client/+/99952/1. 2/src/main/java/com/couchbase/client/java/error/FtsServerOverloadException. java

Hình ảnh kích thước đầy đủ

Quả sung. 5

Ví dụ về thay đổi biểu diễn trực quan khi người đánh giá yêu cầu thay đổi thụt đầu dòng mã. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn trực tuyến

Hình ảnh kích thước đầy đủ

Quả sung. 6

Ví dụ về Thay đổi tổ chức trong đó một phần mã chết đã bị xóa. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn trực tuyến

Hình ảnh kích thước đầy đủ

Quả sung. 7

Ví dụ về thay đổi cách tiếp cận giải pháp. Trong ví dụ này, các hướng dẫn xác nhận đã được thay đổi để có một giải pháp thay thế rõ ràng hơn mà không làm thay đổi chức năng của nó. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn trực tuyến

Hình ảnh kích thước đầy đủ

Quả sung. số 8

Ví dụ về Thay đổi tài nguyên trong đó bộ đệm dữ liệu được đóng để tránh kết quả không mong muốn trong quá trình tính toán. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn

Hình ảnh kích thước đầy đủ

Quả sung. 9

Ví dụ về Kiểm tra thay đổi. Một kiểm tra được đưa ra để đảm bảo rằng phía đối tượng không phải là null. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn

Hình ảnh kích thước đầy đủ

Quả sung. 10

Ví dụ về Thay đổi giao diện giải quyết vấn đề với thứ tự tham số không chính xác. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn

Hình ảnh kích thước đầy đủ

Quả sung. 11

Ví dụ về thay đổi logic. Trong ví dụ đã cho, cần phải di chuyển kiểm tra trạng thái phản hồi để cho phép giải phóng chính xác bộ đệm nội dung. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn

Hình ảnh kích thước đầy đủ

Quả sung. 12

Ví dụ về Thay đổi hỗ trợ, trong đó các mô-đun mới được thêm vào cài đặt cấu hình để cải thiện tính bảo mật và tính ổn định của hệ thống. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn

Hình ảnh kích thước đầy đủ

Quả sung. 13

Ví dụ về Thay đổi lỗi lớn hơn trong đó toàn bộ đoạn mã bị thiếu đã được thêm vào phương thức. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn

Hình ảnh kích thước đầy đủ

Thay đổi chức năng

Thay đổi chức năng là những sửa đổi tác động đến chức năng của hệ thống để đảm bảo luồng chương trình hoạt động chính xác. Dựa trên phân loại được đề xuất bởi Beller et al. (), thay đổi chức năng có thể được chia thành sáu loại

Thay đổi tài nguyên ảnh hưởng đến cách dữ liệu được xử lý. Chúng thường xảy ra để giải quyết các vấn đề về cách mã quản lý dữ liệu

Các thay đổi kiểm tra được giới thiệu để xác minh điều kiện của các biến và chức năng chưa được kiểm tra trước đó (có thể dẫn đến lỗi thời gian chạy)

Thay đổi giao diện tác động đến cách mã tương tác với các phần khác của hệ thống. e. g. , việc sử dụng các tham số không chính xác trong một lệnh gọi hàm

Thay đổi logic giải quyết các vấn đề trong logic của hệ thống. chẳng hạn, khi một thuật toán tạo ra kết quả không chính xác

Thay đổi hỗ trợ giải quyết các vấn đề liên quan đến thư viện hỗ trợ (hoặc hệ thống) và cấu hình của chúng. e. g. , lỗi do sử dụng sai phiên bản của thư viện bên ngoài

Các thay đổi lỗi lớn hơn là các sửa đổi giải quyết các vấn đề chính trong mã, thường trải rộng trên một số lớp. chẳng hạn, khi một lớp còn lại được triển khai một phần

câu hỏi nghiên cứu

Mục tiêu của nghiên cứu này là để hiểu (1) liệu có thể nghĩ ra cách tiếp cận để tự động phân loại các thay đổi đánh giá mã hay không và (2) các nhà phát triển cảm nhận thông tin về các thay đổi đánh giá là hữu ích ở mức độ nào (e. g. , vì những thay đổi này nâng cao nhận thức về kết quả của quy trình xem xét mã trong dự án của họ). Góc nhìn là của cả nhà nghiên cứu và nhà thực hành. Những người đầu tiên quan tâm đến việc khai thác nguồn thông tin mới này để xây dựng các công cụ phân tích và đưa ra các chiến lược mới để hỗ trợ thêm cho các nhà phát triển, trong khi những người thứ hai nhắm đến việc sử dụng thông tin này để cải thiện quy trình và chất lượng tổng thể của hệ thống phần mềm của họ.

Chúng tôi bắt đầu cuộc điều tra của mình bằng cách tập trung vào việc liệu một giải pháp dựa trên máy học có thể tự động phân loại các thay đổi khi xem xét mã thành phân loại được đề xuất trong công việc trước đó hay không (Beller và cộng sự. ; . Một kết quả tích cực sẽ cho chúng ta niềm tin rằng có thể khắc phục các vấn đề về khả năng mở rộng của phương pháp này (Bacchelli và Bird; Beller et al. ; . Do đó, chúng tôi yêu cầu

Theo hiểu biết tốt nhất của chúng tôi, không có nỗ lực nào trước đây được thực hiện để đưa ra các phương pháp tự động phân loại các thay đổi đánh giá. Vì lý do này, trong RQ1, chúng tôi không thể so sánh kết quả của mình với các phương pháp hiện có khác. Trong cuộc điều tra của chúng tôi, chúng tôi đã đánh giá cách tiếp cận của mình theo AUC-ROC, sử dụng làm cơ sở phân loại ngẫu nhiên. Sau khi đạt được kết quả đầy hứa hẹn với phương pháp tự động, chúng tôi tiến hành đánh giá mức độ liên quan của thông tin về các thay đổi đánh giá đối với các học viên. Để thu thập kiến ​​thức chuyên sâu về nhận thức của nhà phát triển về ý nghĩa của phương pháp tiếp cận của chúng tôi cũng như tính hữu ích của việc phân loại các thay đổi đánh giá đối với thực tiễn đánh giá, chúng tôi đưa ra một cuộc điều tra gồm hai bước. Đầu tiên, chúng tôi tiến hành các cuộc phỏng vấn bán cấu trúc với các nhà phát triển để thu thập ý kiến ​​của họ về dữ liệu về các loại thay đổi đánh giá như một phương tiện để hỗ trợ các hoạt động đánh giá mã (e. g. , như một cách để đo lường tác động của việc xem xét mã) và về mức độ phù hợp của phân loại được sử dụng để phân loại. Chúng tôi hỏi

Dựa trên phản hồi thu thập được trong các cuộc phỏng vấn, chúng tôi lập báo cáo dựa trên dữ liệu thay đổi xem xét và điều tra xem các nhà phát triển có kinh nghiệm từ các dự án phần mềm nguồn mở cảm nhận những báo cáo này như thế nào. Vì vậy, câu hỏi nghiên cứu cuối cùng của chúng tôi là

Nghiên cứu của chúng tôi có phương pháp nghiên cứu theo phương pháp hỗn hợp (Johnson và Onwuegbuzie ) bao gồm (1) phân tích định lượng về hiệu suất của phương pháp tự động được điều tra (Domingos), (2) phỏng vấn bán cấu trúc (Longhurst) và (3) khảo sát tùy chỉnh . Các phần tiếp theo mô tả phương pháp và kết quả cho từng câu hỏi nghiên cứu

Q 1. Phân loại các loại thay đổi đánh giá

Bước cần thiết đầu tiên để sử dụng thông tin về các loại thay đổi đánh giá như một phương tiện để hỗ trợ các học viên là khắc phục các vấn đề về khả năng mở rộng hiện có (i. e. , các thay đổi đánh giá phải được phân loại thủ công (Mäntylä và Lassenius ; Bacchelli và Bird ; Beller et al. )). Ở đây, chúng tôi điều tra một cách tiếp cận để tự động phân loại các thay đổi đánh giá và chúng tôi đánh giá độ chính xác của nó. Trong nghiên cứu này, chúng tôi giới hạn trong trường hợp thay đổi mã trong mã nguồn Java

Phương pháp đánh giá

Chúng tôi thiết kế bộ phân loại thay đổi đánh giá được đề xuất dưới dạng giải pháp dựa trên máy học có sẵn trong gói sao chép của chúng tôi. Sự lựa chọn này được thúc đẩy bởi ba yếu tố chính. (1) số lượng dữ liệu đánh giá mã có sẵn (e. g. , trong các dự án sử dụng Gerrit ) làm cho các phương pháp được giám sát trở nên phù hợp thực tế, (2) các hạn chế của các kỹ thuật dựa trên kinh nghiệm, có thể dẫn đến các phương pháp bị giới hạn ở một số . Để điều tra tính chính xác của phương pháp tiếp cận dựa trên máy học, chúng tôi thực hiện các bước sau.

Để chọn các dự án nhằm xây dựng bộ dữ liệu thay đổi đánh giá của chúng tôi, chúng tôi bắt đầu từ Cắt (Paixao et al. ), một bộ dữ liệu đánh giá mã có sẵn công khai và được quản lý. Cắt chứa các dự án sử dụng Gerrit làm nền tảng đánh giá mã và những dữ liệu đánh giá đó . Từ hai cộng đồng (Eclipse và Couchbase) được đại diện trong Cắt , chúng tôi chọn JGit and JavaClient. These projects are (1) Java-based and (2) large open-source systems (ranging from 85k to 145k lines of code). Furthermore, the selected projects possess an active community of developers and reviewers, which makes them ideal targets of our investigation. We limited our selection to two projects from the CROP dataset to ensure that our classification covers a number of cases sufficient to report even the occurrences of uncommon types of changes. On the contrary, covering less cases from a more vast selection of projects might introduce bias in the types of changes contained in our dataset, under-reporting changes that occur less frequently. Moreover, we also consider Android , một trong những dự án được sử dụng rộng rãi nhất trong nghiên cứu đánh giá mã. Android có lịch sử phát triển lâu dài với nhiều nhà phát triển và người đánh giá tích cực, đồng thời đã được chứng minh là có tính đại diện cao cho các hoạt động đánh giá mã của các dự án nguồn mở (Bavota và . , ; . ).

Để xây dựng và đánh giá phương pháp học máy được giám sát, chúng tôi cần thông tin đáng tin cậy về các nhãn thực tế để gán cho các sửa đổi được xem xét (i. e. , một tiên tri về các loại thay đổi mã). Với dữ liệu được gắn nhãn, cách tiếp cận sẽ học từ một tập hợp con các thay đổi được gắn nhãn và có thể được thử nghiệm trên những thay đổi còn lại. Với mục đích này, tác giả đầu tiên của bài báo này đã phân loại thủ công các thay đổi theo phân loại do Beller et al đề xuất. (), dựa trên (1) mã nguồn của từng sửa đổi và (2) nhận xét mã do nhà phát triển để lại trên Gerrit . Đối với mỗi thay đổi được chỉ định cả một danh mục (Khả năng phát triển hoặc chức năng) và một loại. Mô tả của từng loại được cung cấp trong Phần. Những thay đổi này được chọn ngẫu nhiên bằng cách chọn ID đánh giá (i. e. , một mã định danh duy nhất được gán cho một bài đánh giá trong Gerrit) trong số tất cả các bài đánh giá đã hợp nhất trong dự án được xem xét. Sau đó, chúng tôi thực hiện bước thứ hai chọn ngẫu nhiên một bộ bản vá trong số những bản có trong bài đánh giá. Chúng tôi đã loại bỏ bản vá đầu tiên khỏi lựa chọn này vì chúng tôi không quan tâm đến những thay đổi được thực hiện trước khi bắt đầu quá trình xem xét. Quá trình dán nhãn diễn ra từ tháng 3 năm 2019 đến tháng 8 năm 2019.

Trong khi phân tích tập dữ liệu được gắn nhãn, chúng tôi nhận thấy rằng các loại thay đổi, chẳng hạn như Lỗi lớn hơn hoặc Hỗ trợ rất hiếm gặp. Quan sát này đã được xác nhận bởi các nghiên cứu trước đây. Trong phân tích của họ, Mäntylä và Lassenius chỉ tìm thấy 11 thay đổi thuộc về loại khuyết tật lớn hơn và không có thay đổi nào thuộc về loại hỗ trợ (Mäntylä và Lassenius). Kết quả tương tự cũng thu được bởi Beller et al. (). Hơn nữa, tổng số lượng thay đổi chức năng thấp hơn đáng kể so với số lượng thay đổi khả năng tiến hóa. Chỉ có 6. 89% tất cả các thay đổi trong tập dữ liệu của chúng tôi thuộc về danh mục chức năng. Điều này có thể ảnh hưởng đáng kể đến hiệu suất của phương pháp phân loại đã nghĩ ra vì nó sẽ không có đủ các phiên bản của từng loại thay đổi để có thể đưa ra dự đoán chính xác ở cấp độ loại. Vì lý do này, chúng tôi lập luận rằng việc xem xét tất cả mười một nhãn loại có thể tác động tiêu cực đến hiệu suất của phương pháp học máy của chúng tôi

Hạn chế phương pháp phân loại của chúng tôi chỉ hoạt động ở cấp danh mục cũng có thể không phải là một giải pháp hiệu quả. Chúng tôi lập luận rằng thông tin được cung cấp bởi các danh mục có thể quá thô để cung cấp thông tin chi tiết có giá trị trong quy trình xem xét mã. Vì những lý do này, chúng tôi đưa ra khái niệm về nhóm như một mức độ chi tiết trung gian cho các nhãn giữa danh mục và loại. Chúng tôi xác định các nhóm thay đổi như sau. Đề cập đến phân loại được trình bày trong Hình. , chúng tôi tổng hợp các loại thành các lớp cao hơn tương ứng của chúng. Các thay đổi về 'văn bản' và 'được hỗ trợ bởi ngôn ngữ' được coi là các thay đổi về 'tài liệu', trong khi các thay đổi về 'tổ chức' và 'cách tiếp cận giải pháp' là các thay đổi về 'cấu trúc'. Do đó, một nhóm thay đổi có thể là một trong những điều sau đây. 'tài liệu', 'đại diện trực quan', 'cấu trúc' hoặc 'chức năng'. Dựa trên sự cân nhắc này, chúng tôi đã chỉ định cho mỗi thay đổi trong tập dữ liệu của mình một nhãn bổ sung phản ánh nhóm mà thay đổi đó thuộc về. Sau đó, chúng tôi đã thử nghiệm hiệu suất của mô hình ở cả cấp độ danh mục và nhóm

Khi gắn nhãn cho các thay đổi của bài đánh giá, chúng tôi đã chỉ định cùng một ID cho nhiều thay đổi khi chúng được liên kết với nhau một cách hợp lý. e. g. , nhiều thay đổi liên quan đến việc đổi tên cùng một biến (như trong Hình. ). Tuy nhiên, mức độ chi tiết trong cách tiếp cận của chúng tôi là thay đổi mã riêng lẻ mà chúng tôi gọi là sửa đổi (một ví dụ về sửa đổi được hiển thị trong phần

Quả sung. 14

Do đó, ví dụ về các thay đổi đánh giá được liên kết hợp lý, được gắn nhãn bằng cùng một ID. Những thay đổi này đã tạo ra nguồn gốc cho ba sửa đổi. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn https. //git. nhật thực. org/r/c/jgit/jgit/+/49966/3. 4/tổ chức. nhật thực. jgit/src/org/eclipse/jgit/transport/BaseReceivePack. java

Hình ảnh kích thước đầy đủ

Quả sung. 15

Ví dụ về sửa đổi chỉ chứa một đoạn mã cũ. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn https. //git. nhật thực. org/r/c/jgit/jgit/+/1281/5. 6/tổ chức. nhật thực. jgit/src/org/eclipse/jgit/storage/file/FileRepository. java

Hình ảnh kích thước đầy đủ

Quả sung. 16

Ví dụ về sửa đổi chỉ chứa một đoạn mã mới. Đánh giá mã trong thế giới thực trong đó thay đổi này diễn ra có sẵn https. //git. nhật thực. org/r/c/jgit/jgit/+/77733/2. 3/tổ chức. nhật thực. jgit. kiểm tra/tst/org/eclipse/jgit/transport/RefSpecTest. java

Hình ảnh kích thước đầy đủ

Chúng tôi đã khai thác Gerrit để trích xuất các đoạn mã có liên quan cho từng thay đổi đánh giá trong tập dữ liệu được gắn nhãn. Tuy nhiên, API Gerrit không cho phép trích xuất thông tin về liên kết giữa các đoạn mã cũ và mới. Hơn nữa, mặc dù giao diện người dùng Gerrit hiển thị các đoạn mã cũ và mới có liên quan với nhau, nhưng liên kết này được tạo dựa trên số dòng thay đổi chứ không phải nội dung của chúng. Các đoạn mã cũ và mới tác động đến cùng một dòng mã được liên kết với nhau một cách đáng tin cậy. Tuy nhiên, đây không phải là trường hợp khi đoạn mã cũ và mới tác động đến các dòng mã khác nhau. e. g. , khi một khai báo hàm được di chuyển trong một lớp. Vì những lý do này, chúng ta cần tự liên kết các đoạn mã cũ và mới có liên quan. Giữ tách biệt các đoạn mã cũ và mã mới, phương pháp được thiết kế sẽ tính toán khoảng cách Levenshtein (Yujian và Bo ) giữa mỗi đoạn mã cũ và tất cả các mã mới. Quá trình này dẫn đến việc xây dựng biểu đồ hai bên có trọng số, trong đó mỗi đoạn mã là một nút và khoảng cách được tính toán biểu thị trọng số của liên kết. Sau đó, nó chọn cặp có khoảng cách thấp nhất, liên kết chúng thành một sửa đổi và xóa chúng khỏi biểu đồ. Cuối cùng, phương pháp liên kết của chúng tôi tiến hành lặp đi lặp lại giữa các nút còn lại trong biểu đồ. Nếu nhiều liên kết có cùng trọng số, nó dựa trên giả định rằng các đoạn mã liên quan có khả năng có vị trí tương tự trong tệp. Chúng tôi đã thử nghiệm phương pháp liên kết của mình đối với tất cả các sửa đổi có trong tập dữ liệu của mình, sau khi xóa các thay đổi chỉ chứa các câu lệnh nhập. Phương pháp đề xuất đạt độ chính xác 86. 07% và độ chính xác 89%. Hơn nữa, chúng tôi đã xóa các sửa đổi chỉ chứa các câu lệnh nhập vì chúng có thể gây ra sai lệch tiềm ẩn trong phương pháp phân loại. Các khối chỉ chứa các câu lệnh nhập được liên kết hợp lý với các khối mà các thực thể được nhập được sử dụng, chia sẻ một phân loại chung (loại và loại). Sau khi được nhóm thành các sửa đổi, các khối nhập này có thể có các đặc điểm tương tự nhưng khác loại, có khả năng làm giảm hiệu suất của bộ phân loại. Nhìn chung, điều này dẫn đến 2.641 sửa đổi. Mỗi sửa đổi có hai nhãn tương ứng báo cáo danh mục của nó (khả năng phát triển hoặc chức năng) và nhóm của nó (tài liệu, biểu diễn trực quan, cấu trúc hoặc chức năng), tương ứng.

Từ Bảng , chúng tôi thấy rằng các thay đổi về chức năng chiếm ít hơn 7% tổng số các sửa đổi được xem xét, trong khi các thay đổi về 'tài liệu' chiếm 48. 33% của toàn bộ tập dữ liệu, 'đại diện trực quan' 15. 23%, và ‘cơ cấu’ 29 người còn lại. 55%. Sự phân bố các thay đổi như vậy xác nhận những phát hiện đã được báo cáo trước đây trong tài liệu (Mäntylä và Lassenius ; Bacchelli và Bird ; Beller et al. )

Bảng kích thước đầy đủ

Bảng kích thước đầy đủ

Để đánh giá độ tin cậy của các nhãn được gán thủ công, tác giả thứ hai đã thực hiện ghi nhãn độc lập cho một tập hợp con có ý nghĩa thống kê của tập dữ liệu được gắn nhãn (306 thay đổi, dẫn đến mức độ tin cậy là 95% và sai số là 5%). So sánh các nhãn do hai tác giả đưa ra, 90% nhãn loại khớp hoàn toàn cũng như 75% nhãn loại. Trong các trường hợp khác, hai thanh tra viên đã mở một cuộc thảo luận để đạt được sự đồng thuận và bộ dữ liệu đã được điều chỉnh cho phù hợp. Để đo lường sự đồng thuận giữa những người đánh giá giữa hai tác giả, chúng tôi đã tính toán hệ số alpha của Krippendorff (Krippendorff ) đạt được số đo bằng 0. 447 cho nhãn danh mục và 0. 673 cho nhãn loại. Mặc dù giá trị alpha cho nhãn danh mục báo cáo chỉ là một thỏa thuận vừa phải, chúng tôi lập luận rằng điều này phản ánh sự mất cân bằng nội tại trong tập dữ liệu của chúng tôi. Các thay đổi về khả năng tiến hóa xảy ra thường xuyên hơn đáng kể trong quá trình xem xét mã so với các thay đổi về chức năng (Beller et al. ;

Là tính năng của thuật toán máy học, chúng tôi đã chọn các chỉ số có ba phạm vi khác nhau. mã trong đoạn cũ, mã trong đoạn mới và sự khác biệt giữa chúng. Các bảng , và  hiển thị tóm tắt các chỉ số, được nhóm theo phạm vi của chúng (đoạn mã đơn lẻ hoặc toàn bộ sửa đổi) và lý do đằng sau chúng. Cơ sở lý luận đằng sau mỗi số liệu được chọn cho cuộc điều tra của chúng tôi dựa trên tài liệu và quan sát của chúng tôi trong quá trình tạo bộ dữ liệu. Chúng tôi đã kết hợp các số liệu phân tích mã phổ biến (e. g. , LOC, LOCExec hoặc Độ phức tạp theo chu kỳ) với một lựa chọn các chỉ số về khả năng đọc mã. số dấu phẩy hoặc số chu kỳ (Buse và Weimer ). Việc lựa chọn các số liệu này dựa trên phân tích tài liệu về những gì có thể đặc trưng cho loại sửa đổi được thực hiện bởi các nhà phát triển (Fluri et al. ) và những gì có thể nắm bắt được bản chất của mã nguồn dưới các góc nhìn khác nhau. Các chỉ số hoạt động ở cấp độ đoạn mã được tính toán cho cả đoạn mã cũ và đoạn mã mới trong một bản sửa đổi

Bảng 2 Số liệu mã được sử dụng trong phương pháp được đánh giá ở cấp đoạn mã

Bảng kích thước đầy đủ

Bảng 3 Mã số đo được sử dụng trong phương pháp đánh giá ở cấp độ sửa đổi

Bảng kích thước đầy đủ

Bảng 4 Mã số liệu được sử dụng trong phương pháp đánh giá ở cấp độ sửa đổi

Bảng kích thước đầy đủ

Để tính toán các chỉ số đã chọn, chúng tôi đã trích xuất từ ​​ Gerrit đoạn mã của từng thay đổi đánh giá có trong tập dữ liệu của chúng tôi bằng cách sử dụng triển khai Java của Gerrit . Sau đó, dựa trên các đoạn mã đã truy xuất, chúng tôi đã tính toán các chỉ số mã đã chọn. Mã được phát triển để trích xuất và tính toán các số liệu có sẵn trong gói sao chép của chúng tôi như một phần của phương pháp dựa trên máy đã phát minh ra.

Chúng tôi cũng xem xét các nhận xét liên quan đến sửa đổi (nếu có). Chỉ số đầu tiên trong số các chỉ số này là số từ trong nhận xét, chỉ số đếm số từ có trong nhận xét. Khi tính toán số liệu này, chúng tôi coi nhận xét chính và tất cả các câu trả lời của nhận xét đó là một thực thể duy nhất. Giả thuyết của chúng tôi là các sửa đổi thuộc các danh mục hoặc loại khác nhau liên quan đến lượng thảo luận khác nhau (e. g. , yêu cầu thay đổi thuật toán có thể cần nhiều giải thích hơn là thêm một nhận xét bị thiếu). Chúng tôi đã thu thập các nhận xét liên quan đến từng thay đổi mã bằng cách sử dụng triển khai Java của Gerrit REST API, theo cách tương tự như những gì đã thực hiện đối với mã của từng thay đổi. Sau đó, chúng tôi phân tích nội dung các ý kiến. Để đạt được mục đích này, trước tiên chúng tôi tuân theo quy trình chuẩn hóa Truy xuất thông tin điển hình (Baeza-Yates et al. ) liên quan đến mã thông báo, viết thường, loại bỏ từ dừng và xuất phát (Porter). Sau các bước tiền xử lý này, chúng tôi đã tính toán 50 từ thường gặp nhất có tính đến toàn bộ kho nhận xét của tập dữ liệu của chúng tôi. Dựa trên phân tích này, chúng tôi nhóm chúng thành bảy nhóm nhóm các từ chỉ ra một hoạt động tương tự trên mã (e. g. , xóa và xóa). Chúng tôi xác định các nhóm từ có thể giúp bộ phân loại phân biệt giữa các loại thay đổi khác nhau. Nhóm từ được xác định được báo cáo trong Bảng

Bảng 5 Các số liệu thu được từ việc phân tích các nhận xét thay đổi đánh giá

Bảng kích thước đầy đủ

Chúng tôi thử nghiệm với ba bộ phân loại khác nhau. Rừng ngẫu nhiên , J48 và Naive Bayes. We selected these classifiers as they have been successfully applied to solve similar problems in the software engineering domain: e.g., defect prediction (Giger et al. ; Lessmann et al. ; Strüder et al. ) or refactoring recommendation (Pantiuchina et al. ; Kumar et al. ). These classifiers make different assumptions on the underlying data, as well as having different advantages and drawbacks in terms of execution speed and overfitting (Bishop ). In building our approach, we deal with two different classification scenarios: (1) a binary classification to classify a modification in one of the two categories (evolvability or functional); (2) a multi-class classification to assign each modification to one of the four groups (documentation, visual representation, structure, and functional). In the multi-class classification scenario, we estimate multi-class probabilities directly. We do not use techniques such as one-vs-one or one-vs-rest.

Phân tích của chúng tôi cho thấy số lượng câu lệnh if (#Added if và #if diff ) là một trong những biến số nổi bật nhất trong mô hình của chúng tôi (ở cả cấp độ danh mục và cấp độ nhóm). Phần lớn các thay đổi logic và kiểm tra trong số các thay đổi chức năng trong bộ dữ liệu của chúng tôi (tương ứng, 34. 95% và 24. 73% thay đổi chức năng) có thể giải thích tầm quan trọng cao của các biến này trong mô hình của chúng tôi. Cả kiểm tra và thay đổi logic đều liên quan đến việc khắc phục sự cố với kiểm tra và so sánh biến. e. g. , thêm một kiểm tra còn thiếu trên biến được trả về bởi một phương thức. )

Các biến liên quan đến số dòng bình luận cũng được đánh giá là đặc biệt quan trọng (đặc biệt là số LOC trong đoạn mã mới của một sửa đổi). Chúng tôi lập luận rằng số lượng lớn các bình luận LỘC có thể là một dấu hiệu rõ ràng về sự thay đổi tài liệu. Nhìn chung, những thay đổi về tài liệu cấu thành 48. 33% của tất cả các sửa đổi trong bộ dữ liệu của chúng tôi

Chúng tôi kiểm tra phương pháp của mình bằng cách sử dụng tỷ lệ khuếch đại hoặc lựa chọn tính năng dựa trên tương quan. Chúng tôi nhận thấy rằng việc sử dụng lựa chọn tính năng dựa trên tương quan dẫn đến hiệu suất tốt hơn. Vì lý do này, chúng tôi chọn kỹ thuật này và chúng tôi xóa các tính năng không liên quan được báo cáo. Chúng tôi kiểm tra các ngưỡng tương quan khác nhau để loại bỏ các tính năng không liên quan nhằm dự đoán các danh mục và nhóm sửa đổi. Khi đánh giá mô hình của chúng tôi ở cấp danh mục, chúng tôi nhận thấy rằng hiệu suất của mô hình tăng dần cho đến ngưỡng 0. 005 của tương quan được chọn để loại trừ các tính năng không liên quan. Sau đó, hiệu suất của mô hình vẫn ổn định cho đến khi giảm trở lại đối với ngưỡng thậm chí còn nhỏ hơn. Dựa trên những quan sát này, chúng tôi chọn 0. 005 làm ngưỡng lựa chọn tính năng của chúng tôi ở cấp danh mục. Điều này khiến chúng tôi loại trừ các tính năng sau khỏi mô hình của mình. từ phương thức (sửa. giá trị 0. 0044); . giá trị 0. 0031); . giá trị 0. 0030); . giá trị 0. 0009); . giá trị 0. 0001); . giá trị 0). Đối với các nhóm, chúng tôi áp dụng ngưỡng tương quan là 0. 01. Điều này dẫn đến việc bao gồm hầu hết tất cả các tính năng được tính toán trong mô hình của chúng tôi, ngoại trừ Chân đế vì phân tích của chúng tôi cho thấy điều đó không tương quan với biến lớp (corr. giá trị 0)

Chúng tôi xem xét ba khía cạnh tiêu biểu cho việc sử dụng các mô hình máy học. (1) chuẩn hóa dữ liệu (Kotsiatis et al. ), (tôi. e. , giảm không gian đối tượng vào cùng một khoảng thời gian) (2) loại bỏ các đối tượng không liên quan (Chandrashekar và Sahin ), và (3) cân bằng các lớp thiểu số (Krawczyk ). Chúng tôi sử dụng chức năng chuẩn hóa có trong bộ công cụ Weka để chia tỷ lệ dữ liệu ( . ), trong khi chúng tôi đã sử dụng và Lấy mẫu quá mức thiểu số tổng hợp (SMOTE) (Chawla et al. ) để cân bằng dữ liệu, tương ứng. Để triển khai SMOTE trong phương pháp học máy của chúng tôi, chúng tôi đã dựa vào lớp SMOTE do WEKA Java API cung cấp. Sau đó, chúng tôi chạy các trình phân loại máy học đã chọn bằng cách sử dụng tất cả các kết hợp cài đặt (e. g. , không chuẩn hóa dữ liệu nhưng bao gồm lựa chọn tính năng), để chúng tôi có thể xác định giải pháp hiệu quả nhất. Hơn nữa, chúng tôi kiểm tra hiệu suất của các mô hình xem xét cả chiến lược trong và ngoài dự án. Trong trường hợp đầu tiên, chúng tôi đào tạo các mô hình chỉ sử dụng dữ liệu của các dự án đơn lẻ và xác thực hiệu suất của chúng bằng phương pháp xác thực chéo 10 lần (Arlot et al. ); . ) và có cách giải thích kết quả đáng tin cậy hơn, chúng tôi lặp lại việc xác thực mười lần. Trong trường hợp thứ hai, dữ liệu của hai dự án được sử dụng để huấn luyện các mô hình, trong khi dự án còn lại được sử dụng làm bộ kiểm tra; .

Chúng tôi đánh giá mức độ tốt của các mô hình thử nghiệm bằng cách tính toán Độ chính xác, Thu hồi, F-Measure, AUC-ROC và Hệ số tương quan của Matthew (MCC) (Reich và Barai). Các số liệu này cung cấp các quan điểm khác nhau về hiệu suất của phương pháp được điều tra

Để xác định các tính năng có liên quan cho vấn đề phân loại của chúng tôi, chúng tôi áp dụng hai kỹ thuật khác nhau. (1) Lựa chọn thuộc tính Tỷ lệ khuếch đại (Karegowda et al. ) và (2) Lựa chọn tính năng dựa trên tương quan (Hall). Lựa chọn thuộc tính tỷ lệ khuếch đại đánh giá tầm quan trọng của một thuộc tính tính toán tỷ lệ khuếch đại đối với lớp. Bảng báo cáo mười tính năng phù hợp nhất về Tỷ lệ thu được để dự đoán danh mục hoặc nhóm tương ứng. Danh sách đầy đủ các số liệu có sẵn trong gói sao chép của chúng tôi (Fregnan et al. ). Lựa chọn tính năng dựa trên mối tương quan thay vì giá trị của mối tương quan Pearson giữa nó và lớp để đánh giá tầm quan trọng của một tính năng. Bảng  hiển thị mười tính năng có liên quan nhất dựa trên giá trị tương quan của chúng (danh sách đầy đủ các giá trị có sẵn trong gói sao chép của chúng tôi (Fregnan et al. ))

Bảng 6 Tỷ lệ khuếch đại của mười tính năng phù hợp nhất để dự đoán các danh mục hoặc nhóm thay đổi, tương ứng. Khi một số liệu được tính toán ở cấp độ đoạn mã, chúng tôi chỉ định giữa các dấu ngoặc nếu nó liên quan đến đoạn mã mới hoặc đoạn mã cũ trong một sửa đổi

Bảng kích thước đầy đủ

Bảng 7 Giá trị tương quan Pearson của mười tính năng có liên quan nhất để dự đoán các loại hoặc nhóm thay đổi, tương ứng. Khi một số liệu được tính toán ở cấp độ đoạn mã, chúng tôi chỉ định giữa các dấu ngoặc nếu nó liên quan đến đoạn mã mới hoặc đoạn mã cũ trong một sửa đổi

Bảng kích thước đầy đủ

Phân tích kết quả

Tập dữ liệu được gắn nhãn thủ công cuối cùng chứa 1.504 thay đổi với nhãn được chỉ định. Chúng tôi đã phân loại 227 thay đổi đánh giá bổ sung, nhưng đây là những trường hợp ranh giới không thể được chỉ định chính xác cho nhãn với dữ liệu có sẵn, do đó chúng tôi đã loại trừ chúng khỏi tập dữ liệu để không giảm lỗi tiềm ẩn

Bảng  hiển thị kết quả đạt được bởi các mô hình thử nghiệm tốt nhất về F-Measure. Báo cáo về hiệu suất của các mô hình và cấu hình đã thử nghiệm khác có sẵn trong gói sao chép của chúng tôi (Fregnan et al. ). Cấu hình này sử dụng Rừng ngẫu nhiên để dự đoán cả nhãn danh mục và nhãn nhóm, chuẩn hóa dữ liệu và lấy mẫu quá mức cho lớp thiểu số bằng SMOTE. Chúng tôi giữ các cài đặt tham số tiêu chuẩn được cung cấp bởi việc triển khai WEKA của SMOTE. Đặc biệt, thông số phần trăm mặc định của SMOTE được để là 100. Tham số này chỉ định tỷ lệ phần trăm các phiên bản SMOTE mà thuật toán tạo ra. Để tránh đưa ra sai lệch trong hiệu suất của trình phân loại, chúng tôi chỉ áp dụng tái cân bằng lớp với SMOTE cho dữ liệu đào tạo chứ không bao giờ cho dữ liệu thử nghiệm, theo hướng dẫn của Santos et al. (). Các kết quả đã được tính toán kết hợp ba dự án trong tập dữ liệu của chúng tôi và áp dụng xác thực chéo 10 lần mười lần. Ở cấp độ danh mục, mô hình của chúng tôi đã đạt được kết quả đầy hứa hẹn, cho thấy AUC-ROC là 0. 91 và MCC là 0. 61. Hơn nữa, mô hình có thể phân loại các thay đổi về khả năng tiến hóa với độ chính xác và thu hồi bằng 0. 97 và 0. 98 tương ứng, dẫn đến F-Measure bằng 0. 97. Đối với lớp chức năng, chúng tôi đã đạt được số đo F là 0. 63, với độ chính xác và thu hồi bằng 0. 70 và 0. 57, tương ứng. Ở cấp độ nhóm, AUC-ROC được tính cho mỗi nhóm trong số bốn nhóm đều trên 0. 91, đưa ra dấu hiệu đầu tiên về tính khả thi của nhiệm vụ sử dụng mô hình đề xuất.

Bảng 8 Hiệu suất đạt được bằng ba thuật toán Học máy được xem xét (Naive Bayes, J48 và Random Forest) cho các danh mục và nhóm sử dụng SMOTE

Bảng kích thước đầy đủ

Xem xét các kết quả này, các tính năng được chọn dường như là yếu tố dự đoán tốt cho các loại thay đổi đánh giá, do đó gợi ý rằng có thể khắc phục các vấn đề về khả năng mở rộng của các phương pháp trước đây để phân loại các thay đổi đánh giá

Ở cấp danh mục, chúng tôi đã chọn ngưỡng lựa chọn tính năng là 0. 005 (như đã báo cáo trong Mục ). Giá trị này được xác định là một điểm quan trọng trong hiệu suất phân loại. Hiệu suất của bộ phân loại tăng dần cho đến khi đạt đến ngưỡng này, sau đó chúng bắt đầu giảm xuống. Mặc dù vậy, giá trị đã chọn có thể được coi là quá nhỏ và do đó, dẫn đến trang bị quá mức. Để giảm thiểu rủi ro này, chúng tôi đã khám phá hiệu suất của bộ phân loại thay đổi như thế nào đối với các ngưỡng cao hơn, 0. 005 và 0. 01, tương ứng. Bảng báo cáo kết quả mà bộ phân loại của chúng tôi đạt được khi các ngưỡng lựa chọn tính năng này được chọn. Chúng tôi đã sử dụng bộ phân loại hoạt động tốt nhất (Rừng ngẫu nhiên với SMOTE) dựa trên kết quả được báo cáo trong Bảng. Ngay cả đối với các ngưỡng cao hơn, hiệu suất của phương pháp tiếp cận của chúng tôi vẫn ổn định và phù hợp với kết quả được báo cáo trước đó. Điều này, kết hợp với các biện pháp khác được thực hiện để giảm khả năng trang bị thừa, góp phần củng cố niềm tin của chúng tôi vào các phát hiện được báo cáo. Tuy nhiên, công việc tiếp theo có thể được tiến hành để giảm hơn nữa sự thiên vị có thể này. e. g. , bằng cách sử dụng Loại bỏ tính năng đệ quy với xác thực chéo (RFECV)

Bảng 9 Hiệu suất đạt được theo cách tiếp cận của chúng tôi (sử dụng Random Forest và SMOTE) với các ngưỡng tương quan khác nhau

Bảng kích thước đầy đủ

Mặc dù kết quả tổng thể tốt, chúng tôi thực hiện một số quan sát thêm về hiệu suất của mô hình khi phân loại lớp chức năng. Bảng  cho thấy danh mục này có vấn đề nhất. Để hiểu rõ hơn những lý do đằng sau kết quả này, chúng tôi đã tiến hành phân tích định tính sâu hơn. Đầu tiên, số lượng thay đổi chức năng hạn chế đương nhiên hạn chế khả năng của người học máy, vì nó thiếu đủ ví dụ để tìm hiểu đầy đủ cách phân loại chúng Pecorelli et al. (). Bộ dữ liệu của chúng tôi chứa 6. 89% thay đổi đánh giá chức năng. Điều này phù hợp với những phát hiện trước đây đã báo cáo cách các thay đổi chức năng chỉ chiếm một tỷ lệ rất thấp trong tất cả các thay đổi mã xảy ra trong quá trình xem xét mã (Beller et al. ;

Hơn nữa, lớp 'chức năng' bao gồm các thay đổi với các đặc điểm rất khác nhau. thật vậy, một thay đổi về chức năng có thể bao gồm từ một câu lệnh if bị thiếu cho đến việc sửa đổi toàn bộ thuật toán. Nhiều thay đổi lớn này cho một danh mục là một thách thức lớn hơn đối với các giải pháp máy học. Tuy nhiên, hiệu suất đạt được chỉ ra rằng các tính năng được chọn có thể phân biệt hầu hết các thay đổi chức năng trong tập dữ liệu của chúng tôi, do đó thể hiện một đường cơ sở đầy hứa hẹn mà các nhà nghiên cứu khác có thể cải thiện thông qua các cuộc điều tra tiếp theo. Cuối cùng, chúng tôi đã thực hiện một phân tích bổ sung nhằm cải thiện việc phân loại các thay đổi chức năng. Cụ thể, chúng tôi đã đánh giá mức độ phù hợp của việc học nhạy cảm với chi phí (Elkan ). chúng tôi đã chỉ định các trọng số chi phí khác nhau cho các trường hợp chức năng dương và âm giả, do đó thử nghiệm mô hình với các cấu hình ma trận chi phí khác nhau. Tuy nhiên, chúng tôi đã không đạt được bất kỳ cải thiện đáng kể nào, xác nhận rằng cần phải nghiên cứu thêm để cải thiện việc phân loại các thay đổi chức năng.

Kết quả của chúng tôi cho thấy Random Forest đạt được hiệu suất tốt nhất trong số các mô hình được xem xét. Điều này phù hợp với kết quả của các nghiên cứu trước đây đã báo cáo cách Random Forest vượt trội so với Naive Bayes và các thuật toán học máy dựa trên cây quyết định khác (Mahboob et al. ; . ). Ví dụ, trong lĩnh vực công nghệ phần mềm, Random Forest đã được chứng minh là hoạt động tốt hơn các thuật toán khác khi được sử dụng để xây dựng các phương pháp dự đoán lỗi (Kamei et al. ). Rừng ngẫu nhiên là một thuật toán học máy xây dựng nhiều cây quyết định và huấn luyện chúng bằng phương pháp “đóng bao”. So với cây quyết định, rừng ngẫu nhiên chọn ngẫu nhiên các quan sát và tính năng để tạo nhiều cây. Sau đó, hiệu suất cuối cùng được tính bằng cách lấy trung bình kết quả của mỗi cây. Chúng tôi cho rằng những đặc điểm này của rừng ngẫu nhiên có thể là thứ cho phép nó hoạt động tốt hơn các mô hình khác mà chúng tôi đã xem xét trong cuộc điều tra của mình. J-48 (một triển khai của C4. 5) và Naive Bayes

Để hiểu rõ hơn về sự khác biệt giữa các nhóm sửa đổi đánh giá khác nhau, chúng tôi đã điều tra xem tính năng nào phù hợp nhất để phân biệt giữa sửa đổi chức năng hoặc cấu trúc. Để đạt được mục đích này, chúng tôi đã xây dựng một bộ phân loại nhị phân với hai nhóm sửa đổi này (chức năng và cấu trúc) và loại trừ các sửa đổi về tài liệu hoặc biểu diễn trực quan. Sau đó, chúng tôi đã phân tích tầm quan trọng của từng tính năng trong mô hình bằng phân tích tính năng dựa trên tương quan. Chúng tôi báo cáo mười tính năng có liên quan nhất trong Bảng

Bảng 10 Giá trị tương quan Pearson của mười tính năng phù hợp nhất để dự đoán liệu một sửa đổi thuộc về chức năng hay cấu trúc. Khi một số liệu được tính toán ở cấp độ đoạn mã, chúng tôi chỉ định giữa các dấu ngoặc nếu nó liên quan đến đoạn mã mới hoặc đoạn mã cũ trong một sửa đổi

Bảng kích thước đầy đủ

Tính năng quan trọng nhất là số lượng nếu được thêm vào trong một sửa đổi. Hầu hết các lỗi chức năng liên quan đến những thay đổi trong logic của thuật toán hoặc thêm kiểm tra vào các biến. Ngược lại, các sửa đổi khởi tạo đối tượng mới hoặc loại bỏ/thay thế lời gọi phương thức có khả năng thuộc về nhóm cấu trúc. e. g. , các sửa đổi thuộc loại “tiếp cận giải pháp” (một nhóm phụ của sửa đổi cấu trúc) thường liên quan đến việc loại bỏ các phương thức không sử dụng để tăng khả năng bảo trì của mã

Cuối cùng, dựa trên kết quả phân tích tầm quan trọng của tính năng (được báo cáo trong Bảng  và ) và bằng cách so sánh giữa các sửa đổi về chức năng và cấu trúc (có kết quả được minh họa trong Bảng ), chúng tôi chọn một tập hợp con các tính năng có thể đặc biệt liên quan để làm nổi bật sự khác biệt . Đồng thời, chúng tôi mong muốn xác minh các giả thuyết trước đây được hình thành dựa trên kết quả phân tích tầm quan trọng của tính năng. Với mục đích này, chúng tôi đã chọn ba tính năng sau. #nếu đã thêm, #mới thêm và #phương thức đã thêm. Chúng tôi báo cáo trong Bảng  giá trị trung bình và độ lệch chuẩn của các tính năng này đối với từng nhóm sửa đổi bài đánh giá

Bảng 11 Giá trị trung bình và độ lệch chuẩn của #if được thêm vào, #mới được thêm vào và #phương pháp được thêm vào cho từng nhóm trong bốn nhóm sửa đổi đánh giá

Bảng kích thước đầy đủ

Giá trị trung bình của số câu lệnh if được thêm (#Added if ) cao hơn đáng kể đối với các sửa đổi chức năng so với ba nhóm còn lại (tài liệu, biểu diễn trực quan và cấu trúc). Điều này xác nhận giả thuyết trước đây của chúng tôi. Thay đổi chức năng thường yêu cầu bổ sung kiểm tra trên một biến và do đó, số lượng câu lệnh if được thêm vào có thể giúp phân biệt đáng kể giữa thay đổi chức năng và thay đổi khả năng phát triển. Xem xét số lượng khai báo đối tượng mới và lệnh gọi phương thức được thêm vào, chúng tôi nhận thấy rằng giá trị trung bình của cả hai tính năng này khác nhau đáng kể khi so sánh các thay đổi về tài liệu và biểu diễn trực quan với các thay đổi về cấu trúc và chức năng. Chỉ nhìn vào những thay đổi về cấu trúc và chức năng, kết quả của chúng tôi vẫn xác nhận giả thuyết của chúng tôi. Sửa đổi cấu trúc có số lượng đối tượng và phương pháp được thêm vào nhiều hơn, nhưng sự khác biệt với sửa đổi chức năng không quá lớn như mong đợi ban đầu

R Q 2. 1. Đánh giá nhận thức của nhà phát triển

Để thực hiện đánh giá về việc sử dụng thông tin về các loại thay đổi trong quá trình đánh giá như một phương tiện để thông báo cho các học viên về quy trình xem xét và đánh giá mã của họ, chúng tôi tiến hành các cuộc phỏng vấn bán cấu trúc liên quan đến mười hai nhà phát triển có kinh nghiệm đánh giá mã (có các đặc điểm được tóm tắt trong Bảng )

Bảng 12 Thông tin cơ bản của người được phỏng vấn (N = 12)

Bảng kích thước đầy đủ

Sau khi xác minh rằng có thể tự động phân loại các thay đổi đánh giá (do đó khắc phục được vấn đề về khả năng mở rộng của các tác phẩm trước đó (Bacchelli và Bird ; Mäntylä và Lassenius ; Beller et al. )), mục đích của chúng tôi là hiểu cách các học viên cảm nhận thông tin này. Vì lý do này, các mục tiêu của cuộc điều tra này là như sau. (1) thu thập phản hồi của nhà phát triển về phân loại thay đổi đánh giá và khả năng sử dụng thông tin này để hỗ trợ và cải thiện các phương pháp đánh giá mã, (2) tiến hành đánh giá định tính về phân loại đã sử dụng và (3) thu thập phản hồi về cách hiển thị phân loại đã tạo . Trong cuộc điều tra này, chúng tôi đã không xác thực phương pháp học máy của mình. Thay vào đó, chúng tôi tập trung vào cách thông tin về các thay đổi trong bài đánh giá có thể được sử dụng và hiển thị một cách hiệu quả cho người đánh giá

Thiết kế và phương pháp

Mỗi cuộc phỏng vấn có ba phần. (1) Một cuộc thảo luận chung về đánh giá mã, tập trung vào kinh nghiệm của người được phỏng vấn; . ). Tất cả các cuộc phỏng vấn đã được thực hiện dưới dạng phỏng vấn bán cấu trúc (Newcomer et al. ; . Bắt đầu từ ba chủ đề chung nêu trên, việc sử dụng các cuộc phỏng vấn bán cấu trúc cho phép chúng tôi linh hoạt điều chỉnh cấu trúc của cuộc phỏng vấn để đặt câu hỏi tiếp theo khi cần thiết hoặc giải quyết các điểm thảo luận không lường trước được của những người tham gia. Chúng tôi sử dụng một tập hợp các slide để hướng dẫn người tham gia thông qua cấu trúc của cuộc phỏng vấn cũng như để minh họa các khái niệm chính. e. g. , đánh giá thay đổi phân loại. Bộ slide hoàn chỉnh có sẵn trong gói sao chép của chúng tôi

Trong phần đầu tiên, chúng tôi mở một cuộc thảo luận về trải nghiệm tổng thể của những người được phỏng vấn với việc đánh giá mã. Cuộc thảo luận này cho phép chúng tôi thu thập kinh nghiệm cơ bản của người tham gia về đánh giá mã và đặt bối cảnh cho thử nghiệm khái niệm. Sau đó, chúng tôi trình bày cho những người tham gia khái niệm phân loại các thay đổi đánh giá. Đầu tiên, chúng tôi giải thích bằng miệng ý tưởng chung về phân loại các thay đổi trong đánh giá, sau đó chúng tôi hiển thị thông tin này trong bốn PowerPoint trang trình bày. Sử dụng dữ liệu đánh giá mã từ dự án QT, các trang trình bày hiển thị hai giao diện người dùng có thể là Gerrit tiện ích mở rộng. (1) tổng quan chung về các thay đổi của toàn bộ dự án và (2) xem chi tiết về một cam kết cụ thể.

Đối với tổng quan chung, hai biểu diễn thay thế được hiển thị trong hai trang trình bày khác nhau (Hình. và ). Các giao diện người dùng chỉ khác với các biểu đồ được sử dụng để biểu thị các loại thay đổi (biểu đồ hình tròn, biểu đồ, v.v. ). Chúng tôi hiển thị nhiều tùy chọn để hiển thị các biểu diễn thay thế của cùng một dữ liệu. Cả hai trang trình bày đều hiển thị danh sách các thay đổi mới nhất và ba biểu đồ biểu thị toàn bộ loại thay đổi theo thời gian và cho từng nhà phát triển. Một slide bổ sung về tổng quan chung cho thấy sự phát triển của các thay đổi đánh giá theo nhà phát triển, có thể truy cập bằng cách nhấp vào tên của nhà phát triển trong danh sách các thay đổi. Cuối cùng, một slide hiển thị phân loại các thay đổi cho một cam kết cụ thể dưới dạng biểu đồ hình tròn

Quả sung. 17

Chế độ xem đầu tiên của giao diện người dùng tận dụng thông tin về các thay đổi trong đánh giá. Vì lý do dễ đọc, chế độ xem này chỉ chứa hai biểu đồ (trái ngược với ba biểu đồ trong các trang chiếu gốc) và có bố cục khác so với bố cục được hiển thị cho những người tham gia phỏng vấn. Các trang trình bày ban đầu có sẵn trong gói sao chép của chúng tôi (https. //doi. tổ chức/10. 5281/zenodo. 5592254)

Hình ảnh kích thước đầy đủ

Quả sung. 18

Chế độ xem thứ hai của giao diện người dùng tận dụng thông tin về các thay đổi đánh giá, như được hiển thị cho những người tham gia trong các cuộc phỏng vấn. Vì lý do dễ đọc, chế độ xem này chỉ chứa hai biểu đồ (trái ngược với ba biểu đồ trong các trang chiếu gốc) và có bố cục khác so với bố cục được hiển thị cho những người tham gia phỏng vấn. Các trang trình bày ban đầu có sẵn trong gói sao chép của chúng tôi (https. //doi. tổ chức/10. 5281/zenodo. 5592254)

Hình ảnh kích thước đầy đủ

Sau khi trình bày khái niệm phân loại các thay đổi đánh giá, chúng tôi yêu cầu những người được phỏng vấn bày tỏ phản hồi của họ về thông tin này và cách nó được hiển thị; . g. , để xây dựng một công cụ dựa trên dữ liệu thay đổi đánh giá)

Trong bước thứ ba, chúng tôi thảo luận với những người tham gia đánh giá thay đổi phân loại (Beller et al. ). Để giảm thiểu những sai lệch có thể xảy ra, chúng tôi chỉ giới thiệu chi tiết về phân loại trong giai đoạn cuối này. Chúng tôi mong muốn xác thực xem cách phân loại này có phù hợp với kỳ vọng của nhà phát triển hay không. Cụ thể, chúng tôi tập trung vào việc đánh giá xem tất cả các loại trong phân loại có dễ hiểu và phù hợp với trải nghiệm của người được phỏng vấn hay không. Trước khi bắt đầu cuộc thảo luận này, chúng tôi hiển thị phân loại cho những người tham gia và cung cấp cho họ giải thích ngắn gọn về từng danh mục và loại. Do sự phức tạp của phân loại, chúng tôi không giới thiệu các kiểu con thay đổi. Để đánh giá phân loại, chúng tôi yêu cầu người tham gia đưa vào phân loại từng thay đổi được đề cập trong giai đoạn phỏng vấn đầu tiên. Cuối cùng, chúng tôi thảo luận về mức độ khó khăn của họ đối với nhiệm vụ này và liệu họ có gặp phải bất kỳ vấn đề nào không

Các cuộc phỏng vấn được thực hiện thông qua hội nghị truyền hình hoặc gặp trực tiếp và kéo dài khoảng từ 45 phút đến một giờ. Tuy nhiên, chúng tôi không xác định giới hạn thời lượng tối đa nghiêm ngặt. Chúng tôi coi một cuộc phỏng vấn đã kết thúc khi tất cả các chủ đề được xác định trước đã được đề cập và cuộc thảo luận tự nhiên kết thúc. Nghiên cứu được thực hiện bởi một hoặc hai nhà nghiên cứu và tất cả các cuộc phỏng vấn đều được ghi âm và sao chép. Các nhà nghiên cứu thứ hai đã tham gia vào cuộc phỏng vấn đầu tiên để đảm bảo tính tốt của quy trình. Trước khi thực hiện các cuộc phỏng vấn, các tác giả đã nhận được sự chấp thuận của ủy ban đạo đức của tổ chức nhà của họ. Ngoài ra, người được phỏng vấn được yêu cầu ký vào giấy đồng ý tham gia phỏng vấn. Mẫu mô tả phạm vi nghiên cứu

Để phân tích kết quả của các cuộc phỏng vấn, chúng tôi sử dụng phân tích theo chủ đề (Lyons và Coyle). Bước đầu tiên, chúng tôi tạo mã. Mô tả ngắn gọn về nội dung của cuộc phỏng vấn để tóm tắt một ý tưởng được trình bày bởi người được phỏng vấn. Sau đó, chúng tôi xác định các chủ đề phổ biến trên các mã khác nhau. Để tạo chủ đề, chúng tôi nhóm các mã đề cập đến cùng một chủ đề lại với nhau. Cuối cùng, chúng tôi xem xét các chủ đề đã xác định để đảm bảo tính tốt của chúng. e. g. , để tránh trùng lặp giữa các chủ đề khác nhau. Các kết quả đầu tiên được phân tích bởi một trong các tác giả, sau đó được kiểm tra bởi tác giả thứ hai

Những người tham gia

Mười hai người đã tham gia vào các cuộc phỏng vấn bán cấu trúc của chúng tôi về những thay đổi trong đánh giá. Chúng được lựa chọn thông qua quả cầu tuyết của mạng lưới tác giả chuyên nghiệp. Bảng  tóm tắt lý lịch của những người tham gia. Độ tuổi của họ từ 18 đến 44 tuổi, với đa số (9) từ 25 đến 35. Những người tham gia đến từ tám quốc gia khác nhau với ba người đến từ Hoa Kỳ và những người còn lại đến từ Cộng hòa Séc, Pháp, Đức, Ý và các nước châu Âu khác. Mười một người tham gia tự nhận mình là nam, trong khi một người tự nhận mình là nữ. Hiện tại, chín người tham gia làm việc trong các công ty, trong đó một người cũng làm bằng tiến sĩ. D. sinh viên, hai người cũng đóng góp cho các dự án nguồn mở và một học tại trường đại học. Hai người dùng làm việc riêng cho các dự án nguồn mở và một người là sinh viên. Nhìn chung, những người tham gia của chúng tôi có trung bình 11 năm kinh nghiệm viết mã và 5. 3 năm đánh giá mã (std. 4. 7 và tiêu chuẩn. 2. 5, tương ứng). Trung bình 7. 7 năm kinh nghiệm viết mã có được trong quá trình học tập (std. 3) và 9 trong ngành công nghiệp (std. số 8. 6). Những người tham gia báo cáo đã chi trung bình 17. 2 giờ một tuần để đánh giá mã (std. 10. 2). Chín người tham gia sử dụng các công cụ đánh giá mã như GitHub và Crucible

Phân tích kết quả

Phần này tổng quan những phát hiện chính đạt được trong RQ2. 1

Tất cả những người tham gia đều thấy có giá trị và thú vị về khái niệm sử dụng thông tin thu được bằng cách phân loại các thay đổi đánh giá để nâng cao hiểu biết về đánh giá mã. Chẳng hạn, P1 tuyên bố rằng phương pháp đề xuất của chúng tôi có thể giúp các nhóm phần mềm cải thiện quy trình xem xét mã của họ và hiểu vấn đề đang xảy ra ở đâu và ở đâu trong dự án. Tương tự, P12 nói rằng với những tính năng như vậy, các nhà phát triển có thể tránh được những lỗi tương tự trong tương lai. P3 cũng gợi ý rằng một công cụ hiển thị phân tích về các thay đổi khi xem xét có thể cho phép các công ty hiểu được nguồn lực đã được sử dụng ở đâu. Hầu hết các nhà phát triển (mười) đã đề cập đến các nhà quản lý là người phù hợp hoàn hảo cho thông tin do phương pháp của chúng tôi tạo ra; . Họ đã báo cáo thông tin về loại thay đổi đánh giá có thể hữu ích như thế nào đối với người quản lý dự án hoặc trưởng nhóm công nghệ để đánh giá mức độ tốt của các hoạt động đánh giá của họ. Chẳng hạn, P3 giải thích rằng thông tin này có thể tiết lộ liệu nhóm có chú ý đến đúng loại lỗi hay không. Điều này phù hợp với những phát hiện của Bird et al. (). công cụ phân tích đánh giá mã của họ đã trở thành một công cụ có giá trị để các nhà phát triển của Microsoft tự giám sát và cải thiện quy trình đánh giá mã của họ. Để tăng khả năng hành động của thông tin này, những người tham gia phỏng vấn đề xuất so sánh sự phân bổ các thay đổi đánh giá trong dự án của họ với các điểm chuẩn, được tạo ra, ví dụ, bằng cách xem xét các dự án tương tự hoặc lịch sử của dự án được phân tích. Tám người tham gia đã thừa nhận những lợi ích tiềm năng của loại chức năng này

Hơn nữa, những người tham gia của chúng tôi nhận thấy rằng việc hiển thị loại thay đổi cho từng nhà phát triển có thể có vấn đề, chẳng hạn như tạo ra sự cạnh tranh [P12]. Để tránh sự cố này, P11 đề xuất giới hạn quyền truy cập vào thông tin này. Bảy người tham gia cho biết thông tin thú vị nhất là sự phát triển của những thay đổi theo thời gian. P4 cũng tuyên bố rằng một tính năng bổ sung có thể cho phép các nhà phát triển thay đổi mức độ chi tiết (năm, tháng và tuần). P11 và P7 đã đề xuất thêm một biểu đồ, hiển thị cho một thành viên trong nhóm, so sánh nhà phát triển và một người đánh giá tiêu chuẩn lý tưởng, thu được giá trị trung bình của loại thay đổi được tìm thấy bởi tất cả những người đánh giá trong dự án

Sau khi những người tham gia được thông báo về Beller et al. phân loại của (Beller et al. ) và biết định nghĩa của từng danh mục, chúng tôi đã yêu cầu họ đặt một số ví dụ về những thay đổi đánh giá mà họ đã đề cập trong cuộc phỏng vấn trong danh mục phân loại. Tất cả các nhà phát triển có thể liên kết đầy đủ hoặc một phần các thay đổi của họ vào các lớp khác nhau. Trong khi thực hiện tác vụ, tất cả người dùng có thể thấy biểu diễn đồ họa của phân loại trên màn hình (Hình. ). Bốn người tham gia không gặp vấn đề gì khi thực hiện nhiệm vụ này, trong khi năm người có một số nghi ngờ ban đầu về nơi thực hiện thay đổi trong phân loại. Tuy nhiên, sau đó họ đã có thể quyết định trước khi tiến hành

Khi được yêu cầu bình luận về phân loại, năm nhà phát triển đã nói rằng nó có thể có một số vấn đề chồng chéo. Ba người tham gia đề nghị đổi tên một số loại (i. e. , 'Giao diện', 'Lỗi lớn hơn') để giảm nhầm lẫn. Bất chấp những nhận xét này, những người tham gia có thể liên kết hầu hết các thay đổi trong phân loại. Mặc dù người tham gia P9 đã nhận ra một số vấn đề chồng chéo, nhưng anh ấy nói rằng, về tổng thể, mọi thứ khá rõ ràng. Tương tự, P7 nhận thấy rằng các lớp có thể không loại trừ lẫn nhau, nhưng tuyên bố rằng phân loại có đủ sức mạnh mô tả

Nhìn chung, giai đoạn đánh giá này mang lại phản hồi tích cực để thúc đẩy nghiên cứu sâu hơn về phân loại các thay đổi đánh giá để hỗ trợ các học viên (e. g. , như một công cụ phân tích) và cải thiện Beller et al. phân loại của

Các cuộc phỏng vấn tiếp theo

Chúng tôi thực hiện các cuộc phỏng vấn tiếp theo với 7 nhà phát triển từ các cuộc phỏng vấn ban đầu. Mục tiêu của chúng tôi là gấp đôi. (1) Việc đánh giá khái niệm về nhóm, được giới thiệu trong Phần , là tầng trung gian trong quá trình xem xét làm thay đổi cách phân loại; . Mỗi cuộc phỏng vấn được tác giả thứ nhất thực hiện dưới hình thức phỏng vấn bán cấu trúc và kéo dài khoảng 30 phút. Tất cả các cuộc phỏng vấn được thực hiện từ xa. Ngoài ra, để làm rõ các khái niệm được thảo luận trong các cuộc phỏng vấn và hiển thị các ví dụ cho những người tham gia, chúng tôi sử dụng một bộ slide (một ví dụ có sẵn trong gói sao chép của chúng tôi (Fregnan et al. )). Lưu ý rằng trong phần sau, chúng tôi đề cập đến những người tham gia phỏng vấn tiếp theo với mã được gán cho họ trong các cuộc phỏng vấn ban đầu và được báo cáo trong Bảng

Để đánh giá mức độ tốt của các nhóm thay đổi đánh giá, chúng tôi thảo luận với các nhà phát triển. Trước hết, chúng tôi giới thiệu lại khái niệm về các thay đổi đánh giá cũng như tất cả các loại thay đổi được báo cáo trong Beller et al. phân loại của (Beller et al. ) (được báo cáo trong hình. ). Để hỗ trợ cho lời giải thích của chúng tôi, chúng tôi cho những người được phỏng vấn xem slide về phân loại

Tất cả những người được phỏng vấn đều đánh giá tích cực việc giảm phân loại ban đầu thành bốn nhóm được xác định. P10 đã báo cáo cách giảm thành các nhóm dựa trên phân loại ban đầu và không tự ý đưa ra các danh mục mới. Năm người tham gia đã đề cập rằng mức độ chi tiết của phân loại phụ thuộc vào mục tiêu của phương pháp tiếp cận của chúng tôi. Những người tham gia đồng ý rằng mức độ thông tin được cung cấp bởi phương pháp của chúng tôi là đủ, ví dụ, để thông báo cho người quản lý dự án về loại thay đổi xảy ra trong quá trình xem xét mã của họ. Chẳng hạn, P1 đã báo cáo mức độ phù hợp của các nhóm để cung cấp thông tin tổng quan về quy trình xem xét dự án, nhưng mức độ chi tiết tốt hơn là cần thiết để làm cho thông tin này hoàn toàn có thể thực hiện được

Trong phần thứ hai của cuộc phỏng vấn, chúng tôi tiến hành đánh giá ban đầu về hiệu suất của phương pháp phân loại của chúng tôi với các nhà phát triển. Với mục đích này, chúng tôi hiển thị theo thứ tự ngẫu nhiên cho mỗi người tham gia 20 thay đổi đánh giá và yêu cầu họ phân loại từng thay đổi vào một trong bốn nhóm (tài liệu, biểu diễn trực quan, cấu trúc và chức năng). Để chọn các thay đổi, chúng tôi đã áp dụng phương pháp phân loại của mình cho các đánh giá được chọn ngẫu nhiên trong lịch sử đánh giá mã của JGit . Trong số các thay đổi được phân loại kết quả, chúng tôi chọn ngẫu nhiên năm thay đổi cho mỗi nhóm. Mỗi người tham gia được yêu cầu đánh giá một tập hợp các thay đổi đánh giá khác nhau. Chúng tôi không hiển thị cùng một thay đổi cho nhiều người tham gia. Trước khi yêu cầu người tham gia hoàn thành nhiệm vụ này, chúng tôi thảo luận với họ về phân loại thay đổi đánh giá và giới thiệu khái niệm về các nhóm thay đổi đánh giá.

Chúng tôi so sánh cách phân loại do những người tham gia phỏng vấn thực hiện với cách tiếp cận của chúng tôi. Nhìn chung, các nhà phát triển đã đồng ý với cách phân loại phương pháp trong 79. 41% trường hợp. Mặc dù cuộc điều tra này chỉ cấu thành một đánh giá ban đầu về hiệu suất của phương pháp tiếp cận của chúng tôi, nhưng kết quả thu được rất đáng khích lệ. Chúng tôi nhận thấy rằng phần lớn những bất đồng giữa các nhà phát triển và cách tiếp cận của chúng tôi là do những thay đổi về cấu trúc và chức năng. Điều này có thể do sự xuất hiện tương đối giống nhau của hai nhóm thay đổi này. không có kiến ​​thức chuyên sâu về dự án, không phải lúc nào cũng có thể hiểu ngay liệu một thay đổi có ảnh hưởng đến chức năng của mã (do đó, là thay đổi chức năng) hay không

R Q 2. 2. Đánh giá với các dự án mã nguồn mở

trong RQ2. 2, chúng tôi xác minh ý nghĩa của thông tin về các thay đổi đánh giá trên 20 dự án nguồn mở. Mục tiêu chính là phân tích nhận thức của nhà phát triển về dữ liệu đó khi liên quan đến cơ sở mã của riêng họ và do đó, đánh giá tác động của việc tự động phân loại các thay đổi đánh giá đối với các dự án phần mềm đang hoạt động

Thiết kế và cấu trúc

Thiết kế

Để phân tích cách các nhà phát triển nguồn mở cảm nhận thông tin thu được bằng cách tự động phân loại các thay đổi đánh giá, chúng tôi xem xét 20 dự án khác nhau và gửi kết quả phân loại cho các nhà phát triển dưới dạng báo cáo trực tuyến, kèm theo một số câu hỏi để thu thập phản hồi. Chúng tôi đã lập báo cáo của mình theo một phương pháp tương tự như phương pháp được sử dụng trong các nghiên cứu trước đây (Vassallo et al. )

Đối tượng mục tiêu của cuộc điều tra của chúng tôi được đại diện bởi các nhà phát triển chính của mỗi dự án (e. g. , nhà phát triển cốt lõi hoặc chủ sở hữu sản phẩm). để đưa ra phản hồi có giá trị về dữ liệu do phương pháp của chúng tôi tạo ra thực sự cần thiết để có cái nhìn cấp cao và hiểu biết về toàn bộ quy trình xem xét mã của dự án. Những người trả lời được liên hệ bằng cách gửi liên kết đến báo cáo đến danh sách gửi thư của nhà phát triển hoặc diễn đàn dự án, vì các kênh này chủ yếu thu hút sự tương tác của những người đóng góp cốt lõi (Shibuya và Tamai). Trong số 20 dự án (được báo cáo trong Bảng ), ba dự án là hệ thống ban đầu được sử dụng để đào tạo công cụ của chúng tôi (i. e. , Android, JGit và ứng dụng khách Java). Các dự án còn lại được chọn ngẫu nhiên trong số các dự án thuộc cùng cộng đồng với JGit (Eclipse) và Java-client (Couchbase). Chúng tôi tập trung vào các cộng đồng này vì hoạt động đánh giá cao của các nhà phát triển của họ. Hơn nữa, tất cả các dự án được chọn đều tôn trọng các tiêu chí sau. chúng chủ yếu được viết bằng Java và sử dụng Gerrit làm công cụ đánh giá mã.

Bảng 13 Danh sách các dự án đã tạo báo cáo (N = 20) được nhóm theo môi trường

Bảng kích thước đầy đủ

Để tạo báo cáo, chúng tôi trích xuất thông tin về lịch sử xem xét mã của từng dự án bằng cách sử dụng triển khai Java của Gerrit API REST. Chúng tôi sử dụng những dữ liệu này làm thông tin đầu vào cho phương pháp phân loại thay đổi đánh giá của mình (được trình bày trong Phần ). Thông tin được trả về bởi phương pháp phân loại đã nghĩ ra được sử dụng để tạo các biểu đồ hiển thị trong các báo cáo trực tuyến.

Cấu trúc của các báo cáo

Trong báo cáo trực tuyến, sau phần giải thích ngắn gọn về ý nghĩa của các thay đổi xem xét và các loại đã chọn của chúng (i. e. , khả năng phát triển, chức năng, tài liệu, biểu diễn trực quan và cấu trúc), chúng tôi cho nhà phát triển thấy tổng quan về thông tin được thu thập theo phương pháp được thiết kế, cùng với một ví dụ thực tế về từng loại thay đổi được trích xuất từ ​​​​dự án của họ (xem Hình. ). Bên dưới các cam kết mới nhất trên nền tảng Gerrit , chúng tôi hiển thị tổng quan chung về kết quả. Tổng quan hiển thị kết quả ở ba dạng. Một biểu đồ (Hình. a) đại diện cho tổng số đánh giá đã xảy ra trong năm qua. Dữ liệu này nhằm đưa ra ý tưởng về số lượng đánh giá mã được hợp nhất trong dự án. Biểu đồ thứ hai hiển thị tổng số loại thay đổi, được tính toán trong năm qua, trong biểu đồ hình tròn (Hình. b). Cuối cùng, các biểu đồ (Hình. c) đại diện cho các loại thay đổi đánh giá đã xảy ra trong mười hai tháng gần nhất. Do sự khác biệt giữa số lượng thay đổi chức năng và khả năng tiến hóa, hai lớp được hiển thị trong cùng một biểu đồ nhưng với hai tỷ lệ khác nhau. Mặc dù yếu tố này phải được thể hiện rõ ràng từ dữ liệu hiển thị trên biểu đồ đơn của mỗi thay đổi, nhưng chúng tôi cũng thông báo cho các nhà phát triển về hai tỷ lệ khác nhau trong phần mô tả của hình và có nhãn bên dưới biểu đồ. Sau đây, chúng tôi trình bày chi tiết cho những người tham gia cả hai biểu đồ (Hình. b và c) và yêu cầu người phát triển đánh giá thông tin thu được đối với phần tổng quan và đối với từng biểu đồ chi tiết. Chi tiết hơn, chúng tôi hỏi liệu các số liệu có rõ ràng không và liệu thông tin có hữu ích cho người quản lý dự án và nhà phát triển không. Hơn nữa, những người tham gia cũng có thể chỉ ra mức độ hữu ích của toàn bộ báo cáo, liệu họ có nhận thấy rằng họ đã học được điều gì mới từ báo cáo hay không và liệu thông tin này có thể có ảnh hưởng tích cực đến quy trình xem xét mã của họ hay không.

Quả sung. 19

Tổng quan chung được hiển thị cho người tham gia. Các hình ảnh và biểu đồ đã được cắt cho mục đích dễ đọc. một số lượng đánh giá theo thời gian. b Tổng số thay đổi đánh giá cho mỗi nhóm. c Xem xét thay đổi nhóm theo thời gian. Báo cáo ban đầu có sẵn trong gói sao chép (https. //doi. tổ chức/10. 5281/zenodo. 5592254)

Hình ảnh kích thước đầy đủ

Cuối cùng, người tham gia có thể điền thông tin cơ bản để hoàn thành việc thu thập dữ liệu của họ. Chúng tôi cung cấp cho họ khả năng liên hệ với chúng tôi trong trường hợp họ muốn biết thêm chi tiết về công cụ của chúng tôi và kết quả thu được cho dự án của họ. Câu trả lời cho tất cả các câu hỏi, ngoại trừ những câu hỏi yêu cầu câu trả lời mở rộng, được thể hiện bằng thang đo Likert (Likert ) từ 1 (Rất không đồng ý) đến 5 (Rất đồng ý). Tất cả các báo cáo có sẵn trong gói sao chép của chúng tôi

Phân tích kết quả

Trong số 20 báo cáo được gửi, 18 nhà phát triển từ 10 dự án khác nhau đã phản hồi lại cho chúng tôi. 17 người trong số họ đã trả lời bảng câu hỏi của chúng tôi. chúng tôi đã nhận được 15 câu trả lời hoàn chỉnh và 2 câu trả lời một phần. Ngoài ra, năm nhà phát triển cũng đã liên hệ trực tiếp với chúng tôi để đưa ra phản hồi sâu rộng hơn. Tất cả những người trả lời ngoại trừ một người là nhà phát triển cốt lõi, nhà tích hợp (i. e. , nhà phát triển có quyền cam kết/sáp nhập) hoặc chủ sở hữu sản phẩm. Vì lý do này, chúng tôi coi họ là nguồn phản hồi có giá trị vì họ nhận thức đầy đủ về những gì xảy ra trong quá trình xem xét mã. Người tham gia cuối cùng tuyên bố không tham gia vào quá trình phát triển dự án, vì vậy chúng tôi đã loại câu trả lời của họ khỏi phân tích của chúng tôi

Phần lớn những người được hỏi thừa nhận tính mới của thông tin được cung cấp bởi phương pháp được thiết kế cho điểm trung bình là 4. 2 (chuẩn. ≈ 0. 5) cho câu hỏi này trên thang đo Likert. Một nhà phát triển đã nhận xét thêm về giá trị của loại dữ liệu này nhận xét rằng. “điều này cung cấp một cách cụ thể để đo lường một trong những tác động của việc xem xét mã”. Để xác nhận thêm khía cạnh này, một số nhà phát triển đã nói rằng họ đã học được điều gì đó mới về dự án của họ. Ví dụ, một người tham gia báo cáo rằng. “Việc phân bổ các thay đổi trong mỗi nhóm [là] khác với mong đợi”, trong khi một nhóm khác không nhận thức được việc phân bổ các thay đổi theo thời gian

Hơn nữa, chúng tôi đã xác nhận giả thuyết ban đầu của mình về những người dùng tiềm năng của dữ liệu thay đổi đánh giá. Những người tham gia của chúng tôi đồng ý rằng thông tin được cung cấp bởi phần tổng quan (trung bình. 4. 2, tiêu chuẩn. 0. 5), biểu đồ B (trung bình. 3. 9, tiêu chuẩn. 0. 4) và đồ thị C (trung bình. 4. 3, tiêu chuẩn. 0. 4) có thể đặc biệt có giá trị đối với người quản lý dự án. Một trong những nhà phát triển đã báo cáo rằng việc xem xét kỹ hơn quy trình xem xét có thể giúp ban quản lý hiểu rõ hơn về quy trình phát triển. Tuy nhiên, họ cũng đề cập đến khả năng ban quản lý lạm dụng những dữ liệu này. Khả năng như vậy cũng đã được xem xét bởi một số người tham gia thử nghiệm khái niệm của chúng tôi

Ngược lại, và như được tìm thấy trong RQ2. 1, chúng tôi đã nhận được phản ứng nhẹ khi hỏi liệu báo cáo có thể hữu ích cho các nhà phát triển hay không (e. g. , trung bình. 3. 5, tiêu chuẩn. 0. 62 để biết tổng quan). Một nhà phát triển đã bình luận thêm về vấn đề này. “Những loại thống kê này rất tốt cho người quản lý, nhưng không biết điều này sẽ ảnh hưởng như thế nào đến công việc hàng ngày của một kỹ sư?”

Nhìn chung, các nhà phát triển đánh giá tích cực giá trị của thông tin được hiển thị trong các báo cáo. Điều này đã đưa ra một dấu hiệu ban đầu về tính hữu ích tiềm năng của thông tin về các thay đổi đánh giá đối với các học viên. Tuy nhiên, các nghiên cứu sâu hơn cần được tiến hành để đánh giá đầy đủ tính hữu ích của thông tin này. e. g. , tích hợp phương pháp phân loại của chúng tôi vào quy trình đánh giá mã của các dự án hiện có

Là một bước tiếp theo của cuộc điều tra, chúng tôi đã đánh giá các hành động tiềm ẩn đối với quy trình xem xét có thể được kích hoạt bởi thông tin trong báo cáo của chúng tôi. Chúng tôi đã yêu cầu những người tham gia báo cáo cách dữ liệu được hiển thị có thể ảnh hưởng đến các chính sách đánh giá mã, việc sử dụng các công cụ hỗ trợ và phân công người đánh giá. Tuy nhiên, chúng tôi không thể đưa ra bất kỳ kết luận chắc chắn nào về vấn đề này vì chúng tôi nhận được phản hồi trung lập (e. g. , trung bình. 3. 0, tiêu chuẩn. 1. 03 cho các công cụ sử dụng). Chúng tôi lập luận rằng nguyên nhân tiềm ẩn của những kết quả này có thể là do thiếu tài liệu bổ sung và sự tương tác với trực quan hóa của chúng tôi. Chẳng hạn, một trong những người tham gia của chúng tôi nói rằng họ sẽ cần thêm thông tin chi tiết về từng danh mục để nắm bắt đầy đủ tiềm năng của thông tin. Tương tự, một nhà phát triển khác nói rằng họ có thể muốn có thêm thông tin cơ bản về những thay đổi cụ thể được phân loại trong từng danh mục. Nói cách khác, các nhà phát triển đã nhận ra giá trị của thông tin được báo cáo, nhưng đồng thời, yêu cầu hiểu biết bổ sung và có thể là dữ liệu khác để hưởng lợi đầy đủ từ thông tin đó

Thảo luận và ý nghĩa

Kết quả của chúng tôi nêu bật các khía cạnh sẽ được thảo luận thêm

Như đã lưu ý trong ngữ cảnh của RQ1, hầu hết các thay đổi được áp dụng trong đánh giá mã đề cập đến các sửa đổi về khả năng tiến hóa hơn là các sửa đổi về chức năng. Phát hiện này xác nhận kết quả được báo cáo bởi Beller et al. () và hỗ trợ thêm cho nghiên cứu nhằm cải thiện các công cụ phân tích tĩnh để xác định chính xác các vấn đề tiềm ẩn trong mã nguồn (Vassallo et al. ; . ; . ; . ). Hơn nữa, kết quả này gợi ý rằng các nhà phát triển có thể hưởng lợi từ kết quả của các phương pháp phân tích động trong quá trình xem xét mã. chẳng hạn, việc cung cấp cho các nhà phát triển đầu ra của các trường hợp thử nghiệm có thể giúp họ tìm ra các lỗi trong mã nguồn

Trước hết, kết quả đạt được từ cả RQ2. 1 và RQ2. 2 gợi ý rằng thông tin đến từ việc phân tích các thay đổi đánh giá được coi là hữu ích cho người quản lý dự án và có thể là nhà phát triển phần mềm, để hiểu rõ hơn về các loại sửa đổi được thực hiện và đạt được hiểu biết sâu sắc hơn về quy trình đánh giá mã của dự án. Như vậy, mặc dù cách tiếp cận tự động của chúng tôi vẫn còn một số hạn chế khi phân loại các thay đổi chức năng, nhưng đây là bước đầu tiên để đưa loại kiến ​​thức này phục vụ các nhà phát triển. Một mặt, công việc của chúng tôi có ý nghĩa đối với các học viên. Họ có thể áp dụng cách tiếp cận tự động của chúng tôi để cải thiện quy trình xem xét mã của họ thay vì dựa vào phân loại thay đổi mã thủ công tốn thời gian. Mặt khác, công việc của chúng tôi góp phần nâng cao trình độ nghệ thuật trong nghiên cứu đánh giá mã và mở ra hướng đi mới cho các nhà nghiên cứu, những người được kêu gọi điều tra sâu hơn về các hoạt động đánh giá mã và cách cung cấp thông tin có ý nghĩa cho các học viên

Để hỗ trợ phân tích hồi cứu quy trình xem xét mã, chúng tôi hình dung cách tiếp cận của chúng tôi sẽ được tích hợp trong một công cụ được liên kết với kho lưu trữ Gerrit của dự án, phân tích nó theo các khoảng thời gian cố định. Công cụ sẽ hiển thị thông tin này cho các nhà phát triển và quản lý dự án. Kết quả của RQ2. 1 và RQ2. 2 cho phép chúng tôi thu thập một số yêu cầu sơ bộ mà một công cụ như vậy cần phải đáp ứng. Cụ thể, các nhà phát triển đã báo cáo rằng (1) công cụ sẽ hiển thị sự phát triển của thông tin này theo thời gian (i. e. , số lượng thay đổi cho mỗi loại trong một khung thời gian cụ thể), (2) thông tin được hiển thị cần có tính tương tác và (3) công cụ cần cung cấp thông tin cơ bản về từng loại thay đổi

Phương pháp học máy của chúng tôi cũng có thể được sử dụng tại thời điểm đánh giá, có thể được tích hợp dưới dạng trình cắm Gerrit, để hiển thị thông tin về các thay đổi đánh giá trực tiếp trong giao diện người dùng Gerrit. Chúng tôi hình dung trích xuất các thay đổi trong mã cần xem xét, phân loại chúng và trực quan hóa thông tin này dưới dạng cảnh báo cho người dùng. Mỗi cảnh báo sẽ được liên kết với từng sửa đổi (hoặc đoạn mã) để thông báo trước cho người dùng về loại thay đổi mà họ sẽ xem xét. Đối với cả hai kịch bản, điều cơ bản là các công cụ được tạo ra phải được tích hợp tốt vào quy trình làm việc hiện tại của nhà phát triển, như được báo cáo bởi các phát hiện trước đó (Sadowski et al. ; . )

Một trong những kết quả chính của nghiên cứu của chúng tôi liên quan đến việc sử dụng thông tin về các thay đổi đánh giá như một công cụ để hỗ trợ thực hành đánh giá. như đã nêu bởi các nhà phát triển tham gia vào RQ2. 1 và RQ2. 2, thông tin được cung cấp thể hiện tính mới và đưa ra quan điểm mới về cơ chế nội bộ của quy trình xem xét mã. Ngoài ra, một số nhà phát triển nhận xét rằng những dữ liệu này rất thú vị và giúp họ hiểu rõ hơn về các loại thay đổi mà họ tập trung vào trong các bài đánh giá của mình. Tuy nhiên, do những hạn chế của báo cáo tĩnh, các nhà phát triển sẽ khó đánh giá dữ liệu được hiển thị và biến chúng thành các cải tiến khả thi về chất lượng mã của họ. Với những kết quả tích cực, công việc tiếp theo có thể được dành để tạo ra một công cụ hiển thị tương tác dữ liệu thay đổi đánh giá và triển khai nó với các dự án phần mềm trong một nghiên cứu theo chiều dọc, trong đó các nhà phát triển có cơ hội thử nghiệm và tìm hiểu cách sử dụng công cụ đó và nhận được

Chỉ có khoảng 33% thay đổi đánh giá trong tập dữ liệu của chúng tôi là do nhận xét của người đánh giá. Hơn nữa, cùng một nhận xét có thể đã kích hoạt nhiều thay đổi, nhưng khi sử dụng API Gerrit, chúng tôi chỉ có thể liên kết một nhận xét với thay đổi bên cạnh nhận xét đó trong quá trình xem xét. Điều này tiếp tục làm giảm số lượng sửa đổi trong tập dữ liệu của chúng tôi được liên kết với một nhận xét. Nhìn chung, điều này không cho phép chúng tôi sử dụng các kỹ thuật phức tạp hơn để phân tích các nhận xét. Tuy nhiên, các nhận xét đánh giá mã có thể tạo thành một nguồn thông tin đầy hứa hẹn để cải thiện hiệu suất của phương pháp phân loại của chúng tôi. Vì lý do này, chúng tôi tin rằng công việc trong tương lai nên tập trung vào việc phân tích các đặc điểm nhận xét, có thể kết hợp chúng với các đặc điểm mã nguồn bằng cách sử dụng các kỹ thuật vector hóa mã (e. g. , mã2vec). Để áp dụng kỹ thuật này, một nghiên cứu trong tương lai nên giải quyết hai hạn chế hiện tại của phương pháp của chúng tôi. (1) nghĩ ra một cách tiếp cận để liên kết một nhận xét với tất cả các thay đổi đánh giá mà nó gây ra và (2) tăng số lượng được kích hoạt bằng cách đánh giá các thay đổi trong tập dữ liệu

Các mối đe dọa đối với tính hợp lệ

Chúng tôi thảo luận về các mối đe dọa đối với tính hợp lệ của nghiên cứu của chúng tôi và các chiến lược chúng tôi đưa ra để giảm thiểu chúng. Xây dựng hợp lệ. Trong RQ1, tính hợp lệ của các phân tích của chúng tôi có thể đã bị đe dọa bởi tính chính xác của tập dữ liệu thay đổi mà chúng tôi đã tạo thủ công. Việc phân loại các thay đổi có thể đã bị ảnh hưởng tiêu cực bởi loại trải nghiệm và tính chủ quan của người đánh giá. Để đánh giá mức độ của mối đe dọa này, chúng tôi đã tính toán thỏa thuận chung giữa những người đánh giá đạt được kết quả là 90% cho các danh mục và 75% cho các loại (như được giải thích trong Phần ). Để chứng thực thêm những kết quả này, chúng tôi đã tính toán hệ số alpha của Krippendorff thu được giá trị bằng 0. 447 cho các danh mục và 0. 673 cho các loại. Như đã báo cáo trong Phần , hệ số alpha cho các danh mục chỉ cho thấy mức độ đồng thuận vừa phải giữa hai người đánh giá

Bản alpha của Krippendorff tính đến khả năng đạt được thỏa thuận chỉ bằng cách chỉ định ngẫu nhiên một nhãn. Do đó, tập dữ liệu có sự mất cân bằng đáng kể giữa số lượng phần tử trên mỗi nhãn có khả năng đạt được hệ số alpha thấp. Thật không may, đây là một thuộc tính nội tại của hiện tượng được phân tích. Nghiên cứu trước đây đã báo cáo rằng số lượng thay đổi về khả năng tiến hóa trong quá trình xem xét mã cao hơn đáng kể so với số lượng thay đổi chức năng (Beller et al. ; . Tuy nhiên, thỏa thuận vừa phải đạt được khi tính toán alpha của Krippendorff vẫn có thể tạo thành mối đe dọa đối với tính tốt của tập dữ liệu của chúng tôi

Một mối đe dọa tiềm ẩn khác có liên quan đến việc lựa chọn các biến độc lập được sử dụng để xây dựng phương pháp tự động của chúng tôi. Chúng tôi đã khai thác một tập hợp các tính năng nổi tiếng được trình bày trong công việc trước đó và bao gồm các khía cạnh khác nhau về chất lượng mã nguồn, tính dễ hiểu và mạch lạc văn bản (Buse và Weimer ; Palomba et al. Có thể ; . Chúng tôi không thể loại trừ rằng các chỉ số khác, không được xem xét trong nghiên cứu, có thể cung cấp những đóng góp bổ sung cho hiệu suất của mô hình máy học

Trong nghiên cứu này, chúng tôi đã nghĩ ra cách tiếp cận liên kết của riêng mình để kết nối các đoạn mã có liên quan. Tuy nhiên, các cách tiếp cận khác (e. g. , cái được cung cấp bởi java-diff-utils) có thể là những lựa chọn thay thế hợp lệ. Việc sử dụng một phương pháp khác có thể thay đổi hiệu suất của phương pháp phân loại của chúng tôi. Công việc trong tương lai có thể điều tra thêm

Để tiến hành phỏng vấn bán cấu trúc trong bối cảnh của RQ2. 1, trước tiên chúng tôi tạo ra một hướng dẫn thực địa theo các hướng dẫn đã được thiết lập tốt (Bồ Đào Nha ) để tối đa hóa tính chặt chẽ của nghiên cứu. Tuy nhiên, trong quá trình thực hiện, những người được phỏng vấn có thể cung cấp những hiểu biết sâu sắc theo những cách khác nhau, chẳng hạn như. g. , bằng cách trả lời một số câu hỏi được xác định trước trong khi thảo luận về những câu hỏi khác. Vì lý do này, chúng tôi đã điều chỉnh lược đồ phỏng vấn dựa trên các cuộc thảo luận mà chúng tôi đã có với các nhà phát triển; . Giá trị kết luận. Trong RQ1, mối đe dọa đầu tiên liên quan đến việc giải thích hiệu suất đạt được bằng cách tiếp cận. Chúng tôi đã giảm thiểu vấn đề này bằng cách xem xét nhiều hơn một chỉ số đánh giá (e. g. , F-đo, AUC-ROC và MCC). Cũng liên quan đến RQ1, công việc trước đây đã chỉ ra tầm quan trọng của việc xem xét các hành động tiền xử lý dữ liệu để thiết lập đúng các mô hình học máy (Tantithamthavorn et al. ; . ; . ). Vì lý do này, trong nghiên cứu của chúng tôi, chúng tôi đã xem xét việc áp dụng các kỹ thuật để xử lý chuẩn hóa dữ liệu, lựa chọn tính năng, cân bằng dữ liệu và cấu hình siêu tham số. Ngoài ra, chiến lược xác nhận có thể là đối tượng thảo luận. theo một bài báo gần đây (Tantithamthavorn et al. ), xác thực chéo 10 lần có thể làm sai lệch cách giải thích kết quả, vì nó dựa vào việc phân chia ngẫu nhiên dữ liệu được sử dụng để huấn luyện và kiểm tra mô hình. Để giảm thiểu ảnh hưởng của tính ngẫu nhiên, chúng tôi đã lặp lại quá trình xác thực mười lần và báo cáo hiệu suất trung bình đến từ việc chạy mô hình nhiều lần

Bộ dữ liệu về các thay đổi đánh giá của chúng tôi thể hiện sự mất cân bằng đáng kể giữa số lượng thay đổi về khả năng phát triển và chức năng. Điều này phản ánh tỷ lệ của hai loại thay đổi này trong đánh giá mã trong thế giới thực (Beller et al. ; . Tuy nhiên, sự mất cân bằng này trong dữ liệu của chúng tôi làm tăng nguy cơ khiến mô hình của chúng tôi bị quá khớp. Để giảm thiểu sự thiên vị này, chúng tôi đã áp dụng các kỹ thuật sau. (1) Chúng tôi đã thực hiện lựa chọn các tính năng, đánh giá sự đóng góp của từng tính năng cả về tỷ lệ khuếch đại và mối tương quan của Pearson với lớp được dự đoán; . ());

Code review là một quá trình được tiến hành theo trình tự thời gian. Bản chất thời gian của việc xem xét mã có thể ảnh hưởng đến hiệu suất của trình phân loại của chúng tôi. Chúng tôi tin rằng đây không phải là vấn đề đáng lo ngại trong cuộc điều tra của chúng tôi vì chúng tôi không dựa vào các số liệu có thể bị ảnh hưởng bởi tính chất thời gian của quá trình xem xét mã và chúng tôi xử lý từng sửa đổi đánh giá một cách độc lập. Tuy nhiên, chúng tôi kiểm tra tác động có thể có của thứ tự thời gian bằng cách so sánh hiệu suất đạt được theo cách tiếp cận của chúng tôi khi được đánh giá bằng cách sử dụng loại bỏ một lần và sử dụng loại trừ một lần theo thứ tự thời gian. Trong cách tiếp cận đầu tiên, chúng tôi sử dụng lặp đi lặp lại từng sửa đổi trong tập dữ liệu của mình làm bộ thử nghiệm và huấn luyện mô hình bằng cách sử dụng tất cả các sửa đổi khác. Chúng tôi sắp xếp ngẫu nhiên các sửa đổi trong tập dữ liệu của mình để kiểm soát mọi ảnh hưởng theo trình tự thời gian đối với hiệu suất. Trong cách tiếp cận "bỏ một lần theo thứ tự thời gian", chúng tôi đã sắp xếp từng sửa đổi bằng cách sử dụng dấu thời gian liên quan đến sửa đổi mà từ đó nó được trích xuất. Chúng tôi bắt đầu đánh giá bằng cách sử dụng một nửa số sửa đổi được sắp xếp làm tập huấn luyện và sửa đổi được sắp xếp tiếp theo làm tập kiểm tra. Sau đó, chúng tôi thêm sửa đổi này vào tập huấn luyện và chúng tôi chọn sửa đổi tiếp theo làm tập kiểm tra. Chúng tôi tiến hành lặp đi lặp lại cho đến khi không còn sửa đổi nào. So sánh hiệu suất của hai phương pháp, chúng tôi không nhận thấy bất kỳ sự khác biệt đáng kể nào. Kết quả này dường như xác nhận rằng hiệu suất của trình phân loại của chúng tôi không bị ảnh hưởng bởi bản chất tạm thời của việc xem xét mã

trong RQ2. 1 để giảm tính chủ quan của việc đánh giá dữ liệu phỏng vấn, đầu tiên một trong các tác giả đã thực hiện phân tích, sau đó kiểm tra lại kết quả lần thứ hai. trong RQ2. 2, chúng tôi đã đánh giá ý kiến ​​của nhà phát triển về báo cáo được tạo bằng cách dựa trên các câu hỏi mở. Để giảm tính chủ quan, hai tác giả tiến hành phân tích các câu trả lời. Giá trị bên ngoài. Liên quan đến tính khái quát của kết quả, nghiên cứu của chúng tôi xem xét ba dự án mã nguồn mở. Mặc dù chúng tôi đã xem xét các dự án (1) đến từ các lĩnh vực khác nhau, (2) có quy mô cũng như số lượng người đóng góp khác nhau và (3) có cơ cấu tổ chức khác nhau, nhưng chúng tôi không thể xác nhận rằng các kết quả mà chúng tôi đạt được với phương pháp tự động của chúng tôi sẽ giữ nguyên . Trong bối cảnh của RQ2. 1, chỉ có một nhà phát triển nữ tham gia phỏng vấn bán cấu trúc. Các nghiên cứu trước đây cho thấy giới tính có thể ảnh hưởng đến cách mọi người tiếp cận giải pháp cho vấn đề (Beckwith et al. ; . ). Do đó, chúng tôi không thể loại trừ hoàn toàn yếu tố này có thể đã ảnh hưởng đến các câu trả lời thu thập được

Câu trả lời của người tham gia trong RQ2. 1 có thể đã bị ảnh hưởng bởi xu hướng chấp nhận của người điều hành. Để giảm thiểu vấn đề này, chúng tôi nhấn mạnh với những người tham gia bản chất sơ bộ của cuộc điều tra của chúng tôi. Mục đích của chúng tôi không phải là thu thập thông tin về một công cụ mà chúng tôi đã tạo mà chỉ đơn giản là để hiểu được tiềm năng sử dụng và tầm quan trọng của thông tin về các thay đổi trong đánh giá. Những người tham gia không được biết về cách tiếp cận được phát triển trong bối cảnh RQ1 của chúng tôi. Ngoài ra, chúng tôi đã làm rõ với những người được phỏng vấn về cách thức giao diện người dùng của công cụ được hiển thị trong các trang trình bày cuộc phỏng vấn chỉ mang ý nghĩa ví dụ về các ứng dụng của loại thông tin này trong thực tế và không đại diện cho giao diện người dùng của một công cụ hiện có

Chúng tôi đã nhận được 17 câu trả lời khi hỏi các nhà phát triển trong RQ2. 2. Về mặt này, chúng tôi đã nhắm mục tiêu các nhà phát triển ban đầu với mục đích thu thập thông tin chi tiết từ những người có chuyên môn trong quy trình đánh giá mã được phân tích. Như vậy, đối tượng nghiên cứu của chúng tôi bị giới hạn bởi bản chất

Phần kết luận

Chúng tôi đã trình bày một nghiên cứu đánh giá việc phân loại các thay đổi đánh giá như một phương tiện để hỗ trợ các nhà phát triển. Trước tiên, nghiên cứu giải quyết các vấn đề về khả năng mở rộng của các phương pháp được đề xuất trước đây, do tính chất thủ công của chúng, điều tra và đánh giá một kỹ thuật dựa trên máy học có khả năng tự động phân loại các thay đổi đánh giá. Để đạt được mục tiêu này, phương pháp được thiết kế hoạt động bằng cách sử dụng các loại và danh mục thay đổi, dựa trên phân loại được đề xuất bởi các nghiên cứu trước đó (Beller et al. ; . ). Cấu hình tốt nhất của chúng tôi đạt được AUC-ROC là 0. 91 trong việc phân loại các danh mục thay đổi (khả năng phát triển và chức năng) và AUC-ROC giữa 0. 91 và 0. 95 để phát hiện bốn nhóm thay đổi, được tinh chỉnh thêm hai loại chính

Sau đó, chúng tôi đã khám phá việc sử dụng thông tin về các thay đổi đánh giá với mười hai nhà phát triển bằng cách sử dụng các cuộc phỏng vấn bán cấu trúc. Những người tham gia đã cung cấp phản hồi tích cực và ý tưởng để sàng lọc, xác nhận tính tốt của cuộc điều tra của chúng tôi và mở ra những hướng thú vị cho công việc trong tương lai

Cuối cùng, mức độ liên quan của dữ liệu thay đổi đánh giá đối với các học viên được đánh giá bằng cách tạo báo cáo cho 20 dự án nguồn mở khác nhau, được đánh giá bởi 17 nhà phát triển cốt lõi. Các câu trả lời cho báo cáo của chúng tôi đã xác nhận tính mới của thông tin được hiển thị về các thay đổi đánh giá. những người được hỏi tuyên bố không biết về bất kỳ công cụ nào cung cấp thông tin tương tự. Hơn nữa, họ xác nhận các nhà quản lý là mục tiêu tiềm năng chính

Nhìn chung, kết quả điều tra của chúng tôi đưa ra dấu hiệu rõ ràng rằng việc sử dụng thông tin về các thay đổi trong quá trình đánh giá để đánh giá và cải thiện các phương pháp đánh giá hiện tại là khả thi và được các nhà phát triển đánh giá cao

ghi chú

1. gói sao chép trực tuyến. https. //doi. tổ chức/10. 5281/zenodo. 5592254

2. gói sao chép trực tuyến. https. //doi. tổ chức/10. 5281/zenodo. 5592254

3. Đánh giá mã Gerrit. https. //www. gerritcodereview. com

4. API Java Gerrit REST. https. //github. com/uwolfer/gerrit-rest-java-client

5. gói sao chép trực tuyến. https. //doi. tổ chức/10. 5281/zenodo. 5592254

6. lớp SMOTE trong API WEKA JAVA. https. // weka. nguồn. io/doc. gói/SMOTE/weka/bộ lọc/không giám sát/thể hiện/SMOTE. html

7. gói sao chép trực tuyến. https. //doi. tổ chức/10. 5281/zenodo. 5592254

8. QT. https. //wiki. qt. io/Giới thiệuQt

9. GitHub. https. //github. com

10. nồi nấu kim loại. https. //www. người bản địa. com/phần mềm/nồi nấu kim loại

11. Triển khai Java của Gerrit API. https. //github. com/uwolfer/gerrit-rest-java-client

12. gói sao chép trực tuyến. https. //doi. tổ chức/10. 5281/zenodo. 5592254

13. https. //github. com/java-diff-utils/java-diff-utils

Người giới thiệu

• Trang web chính thức của Crucible (2019) https. //www. người bản địa. com/phần mềm/nồi nấu kim loại

• Đánh giá mã Gerrit (2019) https. //www. gerritcodereview. com

• Trang web chính thức của GitHub (2019) https. //github. com

• Về qt (2019) https. //wiki. qt. io/Giới thiệu_Qt

• Abelein U, Paech B (2015) Hiểu ảnh hưởng của sự tham gia và sự tham gia của người dùng đối với sự thành công của hệ thống–một nghiên cứu lập bản đồ có hệ thống. Empir Softw Eng 20(1). 28–81

  Bài báo  Google Scholar

• Android (2020) Kho lưu trữ trực tuyến Android gerrit https. //git. nhật thực. org/r/q/trạng thái. mở + - là. lau

• Arlot S, Celisse A, và cộng sự. (2010) Một cuộc khảo sát về các thủ tục xác thực chéo để lựa chọn mô hình. Khảo sát thống kê 4. 40–79

  Bài viết  MathSciNet  Google Scholar

• Bacchelli A, Bird C (2013) Kỳ vọng, kết quả và thách thức của việc xem xét mã hiện đại. Trong. Kỷ yếu hội thảo quốc tế về công nghệ phần mềm 2013, ICSE ’13. ISBN 978-1-4673-3076-3, https. //doi. tổ chức/10. 1109/ICSE. 2013. 6606617. Nhà xuất bản IEEE, Piscataway, trang 712–721

• Baeza-Yates R, Ribeiro-Neto B, và cộng sự. (1999) Truy xuất thông tin hiện đại, tập 463. Nhà xuất bản ACM, New York

  Google học giả

• Ball T, Kim J-M, Porter AA, Siy HP (1997) Nếu hệ thống kiểm soát phiên bản của bạn có thể nói. Trong. Hội thảo ICSE về mô hình hóa quy trình và nghiên cứu thực nghiệm về công nghệ phần mềm, tập 11

• Baum T, Liskin O, Niklas K, Schneider K (2016) Sơ đồ phân loại theo khía cạnh cho các quy trình xem xét mã công nghiệp dựa trên thay đổi. Trong. Hội nghị quốc tế IEEE 2016 về chất lượng, độ tin cậy và bảo mật phần mềm (QRS), trang 74–85

• Baum T, Leßmann H, Schneider K (2017) Lựa chọn quy trình xem xét mã. Khảo sát về thực trạng thực hành. Trong. Cải tiến quy trình phần mềm tập trung vào sản phẩm. ISBN 978-3-319-69926-4. Springer International Publishing, Chăm, trang 111–127

• Baum T, Schneider K, Bacchelli A (2019) Liên kết dung lượng bộ nhớ làm việc và thứ tự thay đổi mã với hiệu suất xem xét mã. Kỹ thuật phần mềm theo kinh nghiệm, trang 1–37

• Bavota G, Russo B (2015) Bốn mắt tốt hơn hai. về tác động của đánh giá mã đối với chất lượng phần mềm. Trong. 2015 Hội nghị quốc tế IEEE về bảo trì và phát triển phần mềm (ICSME), IEEE, trang 81–90

• Baysal O, Kononenko O, Holmes R, Godfrey MW (2016) Điều tra các yếu tố kỹ thuật và phi kỹ thuật ảnh hưởng đến việc xem xét mã hiện đại. Empir Softw Eng 21(3). 932–959

  Bài báo  Google Scholar

• Beckwith L, Kissinger C, Burnett M, Wiedenbeck S, Lawrance J, Blackwell A, Cook C (2006) Tinkering và giới tính trong quá trình gỡ lỗi của lập trình viên người dùng cuối. Trong. Kỷ yếu hội nghị SIGCHI về Yếu tố con người trong hệ thống máy tính, trang 231–240

• Beller M, Bacchelli A, Zaidman A, Juergens E (2014) Đánh giá mã hiện đại trong các dự án nguồn mở. Họ sửa chữa những vấn đề gì?. Trong. Kỷ yếu hội nghị công tác kho phần mềm khai khoáng lần thứ 11, MSR 2014. ISBN 978-1-4503-2863-0. https. //doi. tổ chức/10. 1145/2597073. 2597082. ACM, New York, trang 202–211

• Bettenburg N, Chỉ S, Schröter A. , Weiss C, Premraj R, Zimmermann T (2008) Điều gì tạo nên một báo cáo lỗi tốt?. Trong. Kỷ yếu của hội nghị chuyên đề quốc tế ACM SIGSOFT lần thứ 16 về nền tảng của công nghệ phần mềm, trang 308–318

• Bird C, Carnahan T, Greiler M (2015) Bài học rút ra từ việc xây dựng và triển khai nền tảng phân tích đánh giá mã. Trong. 2015 Hội nghị làm việc lần thứ 12 của IEEE/ACM về kho phần mềm khai thác, IEEE, trang 191–201

• Bishop CM (2006) Nhận dạng mẫu và học máy. lò xo

• Bosu A, Carver JC (2014) Tác động của danh tiếng nhà phát triển đối với kết quả đánh giá mã trong các dự án oss. một cuộc điều tra thực nghiệm. Trong. Kỷ yếu của hội nghị chuyên đề quốc tế ACM/IEEE lần thứ 8 về kỹ thuật phần mềm thực nghiệm và đo lường, ACM, trang 33

• Burnett MM, Beckwith L, Wiedenbeck S, Fleming SD, Cao J, Park TH, Grigoreanu V, Rector K (2011) Đa nguyên giới trong phần mềm giải quyết vấn đề. Tương tác với máy tính 23(5). 450–460

  Bài báo  Google Scholar

• Buse RPL, Weimer WR (2010) Tìm hiểu số liệu về khả năng đọc mã. IEEE Trans Softw Eng 36(4). 546–558. ISSN 0098-5589. https. //doi. tổ chức/10. 1109/TSE. 2009. 70

  Bài báo  Google Scholar

• Chandrashekar G, Sahin F (2014) Khảo sát về các phương pháp lựa chọn đặc trưng. Máy tính & Kỹ thuật điện 40(1). 16–28

  Bài báo  Google Scholar

• Chawla NV, Bowyer KW, Hall LO, Kegelmeyer WP (2002) Smote. kỹ thuật lấy mẫu quá mức thiểu số tổng hợp. Tạp chí Nghiên cứu Trí tuệ Nhân tạo 16. 321–357

  Bài báo  Google Scholar

• Couchbase (2020) Kho lưu trữ trực tuyến Couchbase Gerrit http. //xem xét lại. đế đi văng. tổ chức/q/trạng thái. mở ra

• Czerwonka J, Greiler M, Tilford J (2015) Đánh giá mã không tìm thấy lỗi. cách thực hành tốt nhất để đánh giá mã hiện tại làm chúng ta chậm lại. Trong. Kỷ yếu hội nghị quốc tế lần thứ 37 về công nghệ phần mềm, Tập 2, IEEE Press, trang 27–28

• Di Penta M, Cerulo L, Aversano L (2009) Sự sống và cái chết của các lỗ hổng được phát hiện tĩnh. Một nghiên cứu thực nghiệm. Inf Softw Technol 51(10). 1469–1484

  Bài báo  Google Scholar

• Domingos PM (2012) Một vài điều hữu ích cần biết về máy học. Acm chung 55(10). 78–87

  Bài báo  Google Scholar

• Eclipse (2020) Kho lưu trữ trực tuyến gerrit của Eclipse https. //git. nhật thực. org/r/q/trạng thái. mở + - là. lau

• Elkan C (2001) Nền tảng của học tập nhạy cảm với chi phí. Trong. Hội nghị chung quốc tế về trí tuệ nhân tạo, tập 17, Lawrence Erlbaum Associates ltd, trang 973–978

• Fagan M (2002) Kiểm tra thiết kế và mã để giảm lỗi trong quá trình phát triển chương trình. Trong. Những người tiên phong về phần mềm, Springer, trang 575–607

• Fink A (2003) Cách thiết kế nghiên cứu khảo sát. Hiền nhân

• Fluri B, Wuersch M, Pinzger M, Gall H (2007) Thay đổi chưng cất. Phân biệt cây để trích xuất thay đổi mã nguồn chi tiết. IEEE Trans Softw Eng 33(11). 725–743

  Bài báo  Google Scholar

• Fregnan E, Petrulio F, Di Geronimo L, Bacchelli A (2020) Điều gì xảy ra trong quá trình đánh giá mã của tôi? . https. //doi. tổ chức/10. 5281/zenodo. 5592254

• Gata W, Grand G, Fatmasari R, Baharuddin B, Patras YE, Hidayat R, Tohari S, Wardhani NK (2019) Dự đoán yếu tố đi học muộn của giáo viên bằng c4. 5, cây ngẫu nhiên, thuật toán rừng ngẫu nhiên. Trong. Hội nghị quốc tế lần thứ 2 về nghiên cứu quản lý và quản lý giáo dục (ICREAM 2018), Atlantis Press, trang 161–166

• Giger E, D'Ambros M, Pinzger M, Gall HC (2012) Dự đoán lỗi ở cấp độ phương pháp. Trong. Kỷ yếu của hội nghị chuyên đề quốc tế ACM-IEEE 2012 về kỹ thuật phần mềm thực nghiệm và đo lường, IEEE, trang 171–180

• Hall M, Frank E, Holmes G, Pfahringer B, Reutemann P, Witten IH (2009) Phần mềm khai thác dữ liệu weka. một bản cập nhật. Bản tin Khám phá ACM SIGKDD 11(1). 10–18

  Bài báo  Google Scholar

• Hall MA (1999) Lựa chọn tính năng dựa trên tương quan cho học máy

• Jiarpakdee J, Tantithamthavorn C, Hassan AE (2019) Tác động của các chỉ số tương quan đối với việc giải thích các mô hình khiếm khuyết. Giao dịch của IEEE về Kỹ thuật phần mềm

• Johnson B, Song Y, Murphy-Hill E, Bowdidge R (2013) Tại sao các nhà phát triển phần mềm không sử dụng các công cụ phân tích tĩnh để tìm lỗi? . Kỷ yếu hội nghị quốc tế về công nghệ phần mềm năm 2013, IEEE Press, trang 672–681

• Johnson RB, Onwuegbuzie AJ ​​(2004) Nghiên cứu theo phương pháp hỗn hợp. một mô hình nghiên cứu đã đến lúc. Nhà nghiên cứu giáo dục 33(7). 14–26

  Bài báo  Google Scholar

• Kamei Y, Matsumoto S, Monden A, Matsumoto K-i, Adams B, Hassan AE (2010) Xem lại các phát hiện dự đoán lỗi phổ biến bằng cách sử dụng các mô hình nhận biết nỗ lực. Trong. 2010 IEEE Hội nghị quốc tế về bảo trì phần mềm, IEEE, trang 1–10

• Kaner C, Falk J, Nguyen HQ (2000) Kiểm thử phần mềm máy tính. tái bản lần 2, Dreamtech press

• Karegowda AG, Manjunath A, Jayaram M (2010) Nghiên cứu so sánh lựa chọn thuộc tính sử dụng tỷ lệ khuếch đại và lựa chọn tính năng dựa trên tương quan. Tạp chí Quốc tế về Công nghệ Thông tin và Quản lý Tri thức 2(2). 271–277

  Google học giả

• Kemerer CF, Paulk MC (2009) Tác động của đánh giá thiết kế và mã đối với chất lượng phần mềm. một nghiên cứu thực nghiệm dựa trên dữ liệu psp. IEEE Trans Softw Eng 35 (4). 534–550

  Bài báo  Google Scholar

• Kononenko O, Baysal O, Guerrouj L, Cao Y, Godfrey MW (2015) Điều tra chất lượng đánh giá mã. Mọi người và sự tham gia có quan trọng không? . Hội nghị quốc tế IEEE 2015 về bảo trì và phát triển phần mềm (ICSME)

• Kotsiantis S, Kanellopoulos D, Pintelas P (2006) Tiền xử lý dữ liệu để nghiêng có giám sát. Khoa học máy tính Int J 1(2). 111–117

  Google học giả

• Kovalenko V, Tintarev N, Pasynkov E, Bird C, Bacchelli A (2020) Đề xuất của người đánh giá có giúp ích cho nhà phát triển không?. IEEE Trans Softw Eng 46(7). 710–731. https. //doi. tổ chức/10. 1109/TSE. 2018. 2868367

  Bài báo  Google Scholar

• Krawczyk B (2016) Học hỏi từ dữ liệu mất cân bằng. mở ra thách thức và định hướng tương lai. Tiến trình trong Artif Intell 5(4). 221–232

  Bài báo  Google Scholar

• Krippendorff K (2011) Tính toán độ tin cậy alpha của krippendorff

• Kumar L, Satapathy SM, Murthy LB (2019) Dự đoán tái cấu trúc cấp phương pháp trên năm dự án java nguồn mở sử dụng kỹ thuật máy học. Trong. Kỷ yếu của hội nghị đổi mới lần thứ 12 về kỹ thuật phần mềm (trước đây gọi là Hội nghị kỹ thuật phần mềm Ấn Độ), trang 1–10

• Lessmann S, Baesens B, Mues C, Pietsch S (2008) Các mô hình phân loại điểm chuẩn để dự đoán lỗi phần mềm. một khuôn khổ đề xuất và những phát hiện mới. IEEE Trans Softw Eng 34(4). 485–496

  Bài báo  Google Scholar

• Likert R (1932) Kỹ thuật đo lường thái độ. Lưu trữ tâm lý học

• Longhurst R (2003) Phỏng vấn bán cấu trúc và nhóm tập trung. Phương pháp chính trong Địa lý 3. 143–156

  Google học giả

• Lyons EE, Coyle AE (2007) Phân tích dữ liệu định tính trong tâm lý học. Nhà xuất bản Sage Ltd

• Mahboob T, Irfan S, Karamat A (2016) Một phương pháp học máy để đánh giá sinh viên trong học trực tuyến bằng c4 của quinlan. 5, bayes ngây thơ và thuật toán rừng ngẫu nhiên. Trong. 2016 Hội nghị đa chủ đề quốc tế lần thứ 19 (INMIC), IEEE, trang 1–8

• Mäntylä MV, Lassenius C (2009) Những loại lỗi nào thực sự được phát hiện trong quá trình đánh giá mã?. Giao dịch của IEEE về Kỹ thuật phần mềm 35(3). 430–448. ISSN 0098-5589. https. //doi. tổ chức/10. 1109/TSE. 2008. 71

  Bài báo  Google Scholar

• McCabe TJ (1976) Một thước đo độ phức tạp. Giao dịch IEEE về Kỹ thuật phần mềm 4. 308–320

  Bài viết  MathSciNet  Google Scholar

• McIntosh S, Kamei Y, Adams B, Hassan AE (2014) Tác động của phạm vi đánh giá mã và sự tham gia đánh giá mã đối với chất lượng phần mềm. một nghiên cứu điển hình về các dự án qt, vtk và itk. Trong. Kỷ yếu hội nghị công tác lần thứ 11 về kho phần mềm khai thác, ACM, trang 192–201

• McIntosh S, Kamei Y, Adams B, Hassan AE (2016) Một nghiên cứu thực nghiệm về tác động của các phương pháp rà soát mã hiện đại đối với chất lượng phần mềm. Empir Softw Eng 21(5). 2146–2189

  Bài báo  Google Scholar

• Morales R, McIntosh S, Khomh F (2015) Các hoạt động rà soát mã có ảnh hưởng đến chất lượng thiết kế không? . Trong. 2015 Hội nghị quốc tế lần thứ 22 của IEEE về phân tích, tiến hóa và tái cấu trúc phần mềm (SANER), IEEE, trang 171–180

• Người mới KE, Hatry HP, Wholey JS (2015) Thực hiện phỏng vấn bán cấu trúc. Sổ tay thẩm định chương trình thực hành, 492

• Ouni A, Kula RG, Inoue K (2016) Đề xuất của người đánh giá ngang hàng dựa trên tìm kiếm trong đánh giá mã hiện đại. Trong. Hội nghị quốc tế IEEE 2016 về bảo trì và phát triển phần mềm (ICSME), IEEE, trang 367–377

• Paixao M, Krinke J, Han D, Harman M (2018) Crop. Liên kết đánh giá mã với các thay đổi mã nguồn. Trong. Hội nghị quốc tế lần thứ 15 của IEEE/ACM 2018 về kho phần mềm khai thác (MSR), trang 46–49

• Palomba F, Panichella A, De Lucia A, Oliveto R, Zaidman A (tháng 5 năm 2016) Một kỹ thuật dựa trên văn bản để phát hiện mùi. Trong. 2016 Hội nghị quốc tế IEEE 24th về hiểu chương trình (ICPC), trang 1–10

• Pantiuchina J, Bavota G, Tufano M, Poshyvanyk D (2018) Hướng tới các đề xuất tái cấu trúc đúng lúc. Trong. 2018 Hội nghị quốc tế IEEE/ACM lần thứ 26 về hiểu chương trình (ICPC), IEEE, trang 312–3123

• Pascarella L, Spadini D, Palomba F, Bruntink M, Bacchelli A (2018) Nhu cầu thông tin trong đánh giá mã đương đại. Proc ACM Hum-Computer Interact 2(CSCW). 135. 1–135. 27. ISSN 2573-0142. https. //doi. tổ chức/10. 1145/3274404

  Bài báo  Google Scholar

• Pecorelli F, Palomba F, Di Nucci D, De Lucia A (2019) So sánh các phương pháp heuristic và machine learning để phát hiện mùi mã dựa trên số liệu. Trong. Kỷ yếu hội nghị quốc tế lần thứ 27 về hiểu chương trình, IEEE Press, trang 93–104

• Porter A, Siy H, Votta L (1996) Đánh giá về kiểm tra phần mềm. tập 42 của Những tiến bộ trong máy tính, trang 39–76. Elsevier

• Porter A, Siy H, Mockus A, Votta L (1998) Hiểu nguồn gốc của sự khác biệt trong kiểm tra phần mềm. ACM Trans Softw Eng Methodol (TOSEM) 7(1). 41–79

  Bài báo  Google Scholar

• Porter MF (1997) Đọc trong truy xuất thông tin. chương Thuật toán loại bỏ hậu tố. Nhà xuất bản Morgan Kaufmann Inc. , San Francisco, trang 313–316. ISBN 1-55860-454-5. http. //dl. cm. tổ chức/trích dẫn. cfm?id=275537. 275705

  Google học giả

• Portigal S (2013) Phỏng vấn người dùng. làm thế nào để khám phá những hiểu biết hấp dẫn. Truyền thông Rosenfeld

• Ram A, Sawant AA, Castelluccio M, Bacchelli A (2018) Điều gì làm cho thay đổi mã dễ dàng hơn để xem lại. Một cuộc điều tra thực nghiệm về khả năng xem xét thay đổi mã. Trong. Kỷ yếu của cuộc họp chung ACM lần thứ 26 năm 2018 về hội nghị kỹ thuật phần mềm châu Âu và hội nghị chuyên đề về nền tảng của kỹ thuật phần mềm, ESEC/FSE 2018, New York, ACM, trang 201–212, ISBN 978-1-4503-5573-5. https. //doi. tổ chức/10. 1145/3236024. 3236080

• Reich Y, Barai S (1999) Đánh giá các mô hình máy học cho các vấn đề kỹ thuật. Artif Intell Eng 13(3). 257–272

  Bài báo  Google Scholar

• Rigby PC, Bird C (2013) Hội tụ các phương pháp bình duyệt phần mềm đương đại. Trong. Kỷ yếu cuộc họp chung lần thứ 9 năm 2013 về nền tảng của công nghệ phần mềm, ACM, trang 202–212

• Rigby PC, German DM, Cowen L, Storey M-A (2014) Đánh giá ngang hàng về các dự án phần mềm mã nguồn mở. Các tham số, mô hình thống kê và lý thuyết. ACM Trans Softw Eng Methodol (TOSEM) 23(4). 35

  Bài báo  Google Scholar

• Sadowski C, Van Gogh J, Jaspan C, Soderberg E, Winter C (2015) Tricorder. Xây dựng hệ sinh thái phân tích chương trình. Trong. 2015 IEEE/ACM 37Th Hội nghị quốc tế IEEE về công nghệ phần mềm, tập 1, IEEE, trang 598–608

• Sadowski C, Aftandilian E, Eagle A, Miller-Cushon L, Jaspan C (2018) Bài học từ việc xây dựng các công cụ phân tích tĩnh tại google. ACM chung 61 (4). 58–66

  Bài báo  Google Scholar

• Santos MS, Soares JP, Abreu PH, Araujo H, Santos J (2018) Xác thực chéo cho các bộ dữ liệu mất cân bằng. Tránh các cách tiếp cận quá lạc quan và quá phù hợp [giới hạn nghiên cứu]. IEEE Comput Intell Mag 13(4). 59–76

  Bài báo  Google Scholar

• Sauer C, Jeffery DR, Land L, Yetton P (2000) Tính hiệu quả của các đánh giá kỹ thuật phát triển phần mềm. một chương trình nghiên cứu có động cơ hành vi. IEEE Trans Softw Eng 26(1). 1–14

  Bài báo  Google Scholar

• Shibuya B, Tamai T (2009) Tìm hiểu quy trình tham gia cộng đồng mã nguồn mở. Trong. Kỷ yếu hội thảo ICSE 2009 về các xu hướng mới nổi trong nghiên cứu và phát triển phần mềm Tự do/Tự do/Nguồn mở, IEEE Computer Society, trang 1–6

• Spadini D, Aniche M, Storey M-A, Bruntink M, Bacchelli A (2018) Khi thử nghiệm đáp ứng đánh giá mã. Tại sao và làm thế nào các nhà phát triển xem xét các bài kiểm tra. Trong. 2018 Hội nghị quốc tế IEEE/ACM lần thứ 40 về công nghệ phần mềm (ICSE), IEEE, trang 677–687

• Spadini D, Palomba F, Baum T, Hanenberg S, Bruntink M, Bacchelli A (2019) Đánh giá mã dựa trên thử nghiệm. Một nghiên cứu thực nghiệm. Trong. Kỷ yếu của hội nghị quốc tế lần thứ 41 về công nghệ phần mềm, IEEE Press, trang 1061–1072

• Strüder S, Mokelabai M, Strüber D, Berger T (2020) Dự đoán lỗi theo định hướng tính năng. Trong. Kỷ yếu hội nghị ACM lần thứ 24 về hệ thống và dòng sản phẩm phần mềm. Tập A-Tập A, trang 1–12

• Tantithamthavorn C, Hassan AE (2018) Báo cáo kinh nghiệm về lập mô hình lỗi trong thực tế. Cạm bẫy và thách thức. Trong. Kỷ yếu hội nghị quốc tế lần thứ 40 về công nghệ phần mềm. công nghệ phần mềm trong thực tế, ACM, trang 286–295

• Tantithamthavorn C, McIntosh S, Hassan AE, Matsumoto K (2016) So sánh thực nghiệm các kỹ thuật xác thực mô hình cho các mô hình dự đoán lỗi. IEEE Trans Softw Eng 43(1). 1–18

  Bài báo  Google Scholar

• Tantithamthavorn C, McIntosh S, Hassan AE, Matsumoto K (2018) Tác động của tối ưu hóa tham số tự động đối với các mô hình dự đoán lỗi. Giao dịch của IEEE về Kỹ thuật phần mềm

• Thongtanunam P, McIntosh S, Hassan AE, Iida H (2015a) Điều tra các hoạt động rà soát mã trong các tệp bị lỗi. một nghiên cứu thực nghiệm về hệ thống qt. Trong. Kỷ yếu hội nghị làm việc lần thứ 12 về kho phần mềm khai thác, IEEE Press, trang 168–179

• Thongtanunam P, Tantithamthavorn C, Kula RG, Yoshida N, Iida H, Matsumoto K. -tôi. (2015b) Ai nên xem lại mã của tôi? . Trong. 2015 Hội nghị quốc tế lần thứ 22 của IEEE về phân tích, tiến hóa và tái cấu trúc phần mềm (SANER), IEEE, trang 141–150

• Thongtanunam P, McIntosh S, Hassan AE, Iida H (2016) Xem xét lại quyền sở hữu mã và mối quan hệ của nó với chất lượng phần mềm trong phạm vi xem xét mã hiện đại. Trong. Kỷ yếu của hội nghị quốc tế lần thứ 38 về công nghệ phần mềm, ACM, trang 1039–1050

• Vassallo C, Panichella S, Palomba F, Proksch S, Zaidman A, Gall HC (2018) Bối cảnh là quan trọng nhất. quan điểm của nhà phát triển về việc sử dụng các công cụ phân tích tĩnh. Trong. 2018 Hội nghị quốc tế IEEE lần thứ 25 về phân tích, tiến hóa và tái cấu trúc phần mềm (SANER), IEEE, trang 38–49

• Vassallo C, Panichella S, Palomba F, Proksch S, Gall HC, Zaidman A (2019a) Cách các nhà phát triển tương tác với các công cụ phân tích tĩnh trong các ngữ cảnh khác nhau. Kỹ thuật phần mềm thực nghiệm

• Vassallo C, Proksch S, Gall HC, Di Penta M (2019a) Tự động báo cáo các lỗi không đúng mẫu và phân rã trong tích hợp liên tục. Trong. 2019 IEEE/ACM Hội nghị quốc tế lần thứ 41 về Kỹ thuật phần mềm (ICSE), IEEE, trang 105–115

• Wiegers K (2002) Đánh giá ngang hàng về phần mềm. Hướng dẫn thực hành. Công ty xuất bản Addison-Wesley Longman. , Inc. , Boston. ISBN 0-201-73485-0

  Google học giả

• Wolf T, Schroter A, Damian D, Nguyen T (2009) Dự đoán lỗi xây dựng bằng cách sử dụng phân tích mạng xã hội về giao tiếp của nhà phát triển. Trong. 2009 Hội nghị quốc tế IEEE 31St về công nghệ phần mềm, IEEE, trang 1–11

• Yujian L, Bo L (2007) A normalized levenshtein distance metric. IEEE Trans Pattern Anal Mach Intell 29(6). 1091–1095. ISSN 0162-8828. https. //doi. tổ chức/10. 1109/TPAMI. 2007. 1078

  Bài báo  Google Scholar

• Zanjani MB, Kagdi H, Bird C (2015) Tự động giới thiệu người đánh giá ngang hàng trong đánh giá mã hiện đại. IEEE Trans Softw Eng 42(6). 530–543

  Bài báo  Google Scholar

Tải tài liệu tham khảo

Nhìn nhận

Các tác giả xin cảm ơn những người phản biện ẩn danh vì những nhận xét sâu sắc và quan trọng của họ và xin chân thành cảm ơn sự hỗ trợ của Quỹ Khoa học Quốc gia Thụy Sĩ thông qua Dự án SNF No. PP00P2_170529

Kinh phí

Tài trợ truy cập mở được cung cấp bởi Đại học Zurich

thông tin tác giả

Tác giả và Chi nhánh

1. Đại học Zurich, Zurich, Thụy Sĩ

   Enrico Fregnan, Fernando Petrulio, Linda Di Geronimo & Alberto Bacchelli

tác giả

1. Enrico Fregnan

   Xem các ấn phẩm của tác giả

   Bạn cũng có thể tìm kiếm tác giả này trong PubMed   Google Scholar

2. Fernando Petrulio

   Xem các ấn phẩm của tác giả

   Bạn cũng có thể tìm kiếm tác giả này trong PubMed   Google Scholar

3. Linda Di Geronimo

   Xem các ấn phẩm của tác giả

   Bạn cũng có thể tìm kiếm tác giả này trong PubMed   Google Scholar

4. Alberto Bacchelli

   Xem các ấn phẩm của tác giả

   Bạn cũng có thể tìm kiếm tác giả này trong PubMed   Google Scholar

Đồng tác giả

Thư từ Enrico Fregnan

Thông tin thêm

giao tiếp bởi. Emerson Murphy-Hill

Ghi chú của nhà xuất bản

Springer Nature vẫn giữ thái độ trung lập đối với các tuyên bố về quyền tài phán trong các bản đồ đã xuất bản và các tổ chức liên kết

Quyền và quyền

Truy cập Mở Bài viết này được cấp phép theo Creative Commons Attribution 4. 0 Giấy phép Quốc tế, cho phép sử dụng, chia sẻ, điều chỉnh, phân phối và sao chép ở bất kỳ phương tiện hoặc định dạng nào, miễn là bạn cung cấp tín dụng phù hợp cho (các) tác giả gốc và nguồn, cung cấp liên kết đến giấy phép Creative Commons và cho biết . Hình ảnh hoặc tài liệu của bên thứ ba khác trong bài viết này được bao gồm trong giấy phép Creative Commons của bài viết, trừ khi có quy định khác trong hạn mức tín dụng đối với tài liệu. Nếu tài liệu không có trong giấy phép Creative Commons của bài viết và mục đích sử dụng của bạn không được phép theo quy định pháp luật hoặc vượt quá mức sử dụng được phép, bạn sẽ cần xin phép trực tiếp từ người giữ bản quyền. Để xem bản sao của giấy phép này, hãy truy cập http. //Commons sáng tạo. org/giấy phép/bởi/4. 0/

In lại và Quyền

Về bài viết này

Trích dẫn bài viết này

Frennan, E. , Petrulio, F. , Di Geronimo, L. et al. Điều gì xảy ra trong đánh giá mã của tôi? . Empir Software Eng 27, 89 (2022). https. //doi. tổ chức/10. 1007/s10664-021-10075-5

Cuộc họp đánh giá mã là gì?

Đánh giá mã nên bao gồm những gì?

Các bước chính liên quan đến quá trình xem xét mã là gì?

Quy trình xem xét mã là gì?