Dùng khoa học dữ liệu để khám phá phát triển phần mềm

Khoa học dữ liệu có ý nghĩa gì đối với phát triển phần mềm? Trong bài viết blog này, bạn sẽ khám phá một số nghiên cứu tình huống thú vị về khoa học dữ liệu trong kỹ thuật phần mềm!

Đã cập nhật 4 thg 10, 2026 · 9 phút đọc

Khám phá cùng AI

ChatGPT Claude Perplexity

Nhiều nhà phát triển phần mềm đang học khoa học dữ liệu để phân tích dữ liệu của khách hàng. Ngày càng nhiều người nhận ra rằng họ có thể dùng chính những kỹ thuật đó để trả lời các câu hỏi của riêng mình, chẳng hạn như:

Khi nào dự án này sẽ sẵn sàng phát hành?
Những thành phần nào của ứng dụng cần được kiểm thử nhiều nhất?
Ai nên sửa lỗi này?
Phần nào của API của tôi khiến mọi người thấy khó sử dụng nhất?

Trong 15 năm qua, đã có một làn sóng nghiên cứu thực nghiệm trong kỹ thuật phần mềm nhằm khám phá những câu hỏi này, một phần nhờ dữ liệu sẵn có từ các trang như GitHub và Stack Overflow. Bài viết blog này giới thiệu một vài kết quả tiêu biểu, sau đó đi sâu hơn vào phương pháp đằng sau ba nghiên cứu.

Nếu bạn muốn biết thêm về cách sử dụng khoa học dữ liệu để có được những hiểu biết như vậy cho các dự án của riêng bạn, hãy cho tôi biết.

Khoa học dữ liệu và Kỹ thuật phần mềm: Ví dụ

Hãy bắt đầu với một phát hiện ảnh hưởng đến mọi người làm khoa học dữ liệu ở quy mô lớn: khám phá của Yuan và cộng sự rằng kiểm thử đơn giản có thể ngăn chặn hầu hết các lỗi nghiêm trọng trong các hệ thống phân tán xử lý dữ liệu lớn. Họ đã xem xét lỗi trên Cassandra, Hadoop MapReduce và các hệ thống tương tự và nhận thấy rằng:

Hầu như tất cả lỗi đều cần 3 nút tính toán trở xuống để tái hiện. Tức là, bạn thường không cần cả một cụm để gỡ lỗi cho một cụm.
Nhật ký lỗi thường chứa đủ dữ liệu để cho phép tái hiện.
Phần lớn các lỗi thảm họa lẽ ra có thể dễ dàng được ngăn chặn bằng cách thực hiện kiểm thử đơn giản trên mã xử lý lỗi.

Điểm cuối cùng là điều bất ngờ nhất. Trong khi các chuyên gia thường kiểm thử rằng mã phân tích hoạt động khi mọi thứ diễn ra suôn sẻ, họ hiếm khi kiểm thử rằng nó xử lý đúng khi có sự cố. Chỉ cần thêm vài bài kiểm thử như vậy trong quá trình phát triển sẽ ngăn được rất nhiều rắc rối về sau.

Một kết quả quy mô lớn khác đến từ công trình của Altadmri và Brown, những người đã xem xét 37 triệu lần học sinh trung học ở Vương quốc Anh cố gắng biên dịch chương trình. Sau đó họ hỏi giáo viên xem lỗi phổ biến nhất của học sinh là gì, và phát hiện rằng:

Các giáo viên không đồng ý với nhau về những lỗi mà học sinh có khả năng mắc phải nhất.
Quan trọng hơn, dự đoán của giáo viên chỉ tương quan yếu với những gì học sinh thực sự làm sai.

Tất nhiên, khai phá dữ liệu không phải là cách duy nhất để tạo ra những hiểu biết hữu ích dựa trên bằng chứng trong lập trình. Năm 2013, nhóm của Andreas Stefik đã công bố nghiên cứu thứ hai trong chuỗi nghiên cứu xem liệu một số ngôn ngữ có dễ học hơn những ngôn ngữ khác hay không. Làm chuẩn so sánh, họ đưa vào nghiên cứu một ngôn ngữ giả có các từ khóa được tạo ngẫu nhiên.

Thật bất ngờ, các ngôn ngữ dùng dấu ngoặc nhọn như Java và Perl khó để người mới học nhận diện như một ngôn ngữ được tạo ngẫu nhiên. Python và Ruby đều dễ học hơn đáng kể, và Quorum, vốn A/B test cú pháp cho mọi tính năng mới trước khi bổ sung, còn dễ hơn nữa. Andreas bàn về kết quả này và lý do tại sao các nhà thiết kế ngôn ngữ lập trình ít chú ý đến khả năng sử dụng trong podcast thú vị này.

Nhận diện báo cáo lỗi bảo mật

Ví dụ về cách thực hiện các nghiên cứu này, Fayola Peters tại LERO đã dùng các mô hình dự đoán dựa trên văn bản để tìm các báo cáo lỗi bảo mật trong trình theo dõi lỗi của các hệ thống lớn nhằm ưu tiên xử lý. Trong một nghiên cứu, cô sử dụng dữ liệu từ các dự án Chromium, Wicket, Ambari, Camel và Derby; những dự án này có tổng cộng 45.940 báo cáo lỗi, nhưng chỉ 0,8% là báo cáo lỗi bảo mật.

Một số lỗi bảo mật được gán nhãn thủ công và có thể dùng để huấn luyện bộ phân loại nhằm phát hiện các lỗi chưa gán nhãn. Các kỹ thuật như Naïve Bayes và Random Forests là điểm khởi đầu, nhưng hiệu quả của các mô hình tổng quát thường có thể cải thiện nhờ lọc theo các từ khóa cụ thể. Kiểm tra quan trọng nhất là các mô hình xây dựng từ những dự án có lỗi bảo mật đã gán nhãn phát hiện được lỗi tương tự ở dự án khác tốt đến đâu. Kết quả rất đáng khích lệ: Peters nhận thấy các bộ phân loại của cô đủ tốt để hữu dụng trong thực tế.

Bản vá của tôi có được chấp nhận không?

Ví dụ thứ hai, các công ty muốn sửa đổi của họ được đưa vào dự án để tránh phải tự bảo trì mã, và tình nguyện viên cũng muốn biết liệu bản vá của họ có cơ hội hay không. Vì thường có một khoảng thời gian dài giữa lúc gửi và lúc chấp nhận bản vá, Bram Adams và nhóm của ông tại Polytechnique Montréal đã xây dựng các mô hình để dự đoán bản vá nào sẽ được chấp nhận.

Giống nhiều dự án khoa học dữ liệu khác, dự án này bắt đầu bằng việc lấy và làm sạch dữ liệu từ nhiều nguồn, bao gồm kho Git và đánh giá mã trên Gerrit. Tuy nhiên, với các dự án dùng đánh giá qua email, như nhân Linux, việc thu thập dữ liệu đồng nghĩa với việc quét lưu trữ danh sách thư và dùng các heuristic như checksum của bản vá hoặc giao cắt theo tập các dòng thay đổi để khớp bản vá với cuộc thảo luận. Ngay cả với sự hỗ trợ của các công cụ như GrimoireLab, luôn có những bản vá có nhiều phiên bản được đánh giá, và những bản vá tách thành nhiều phần được đánh giá riêng rẽ. Như trong mọi dự án khoa học dữ liệu, nhà phân tích phải xây dựng mô hình, và các giả định trong đó sẽ tác động mạnh đến kết luận cuối cùng.

Bước thứ hai là quyết định những biến số cần xem xét và chỉ số dùng cho mỗi biến, chẳng hạn như:

chất lượng bản vá
kinh nghiệm của nhà phát triển bản vá
quy trình đánh giá (ví dụ, bình luận đánh giá và số lượng người đánh giá)
chất lượng đánh giá (ví dụ, mức độ chi tiết của đánh giá)
thời gian đánh giá
sự tương tác giữa tác giả bản vá và người đánh giá (ví dụ, thân thiện so với giận dữ)

Chỉ riêng nửa tá yếu tố này có thể cần mọi thứ từ thống kê sống sót đến phân tích cảm xúc. Khi đã quyết định những gì cần đo, bạn có thể áp dụng các công cụ khoa học dữ liệu mà các khóa học của DataCamp dạy. Vì mục tiêu thực sự của bạn là dự đoán việc chấp nhận các bản vá trong tương lai, cách tiếp cận trực diện nhất là hồi quy logistic, nhưng còn nhiều phương pháp khác.

Cuối cùng, bạn có thể đo tầm quan trọng của biến để xác định tác động của từng biến lên việc chấp nhận bản vá. Điều này tất yếu sẽ mang tính định tính một phần, vì mục tiêu của bạn là xác định những việc nhà phát triển có thể làm để cải thiện cơ hội đưa công việc của họ vào sản phẩm. Như mọi khi, bạn phải cẩn trọng tránh nhầm lẫn giữa tương quan và nhân quả, nhưng ngay cả vài khuyến nghị đơn giản (như "ĐỪNG DÙNG CHỮ IN HOA TOÀN BỘ TRONG THÔNG ĐIỆP COMMIT CỦA BẠN") cũng có thể tạo khác biệt thực sự.

Tìm kiếm trợ giúp

Sự thay đổi lớn nhất trong cách lập trình viên làm việc trong 20 năm qua không nằm ở ngôn ngữ họ dùng: đó là sự phụ thuộc gần như phổ quát vào Stack Overflow để đặt câu hỏi và nhận câu trả lời. Christoph Treude tại Đại học Adelaide và cộng sự đã phát triển các phương pháp giúp những trang như vậy hữu ích hơn.

Điểm khởi đầu của họ là bộ dữ liệu Stack Overflow. Sau khi làm một số thống kê khám phá để xem số lượng từ và câu, các từ phổ biến nhất, tần suất xuất hiện–tần suất nghịch đảo theo tài liệu (TF-IDF), v.v., bước tiếp theo là xem những từ nào trong các chuỗi thảo luận trên Stack Overflow đồng xuất hiện với số phiếu cao hơn, tỷ lệ chấp nhận cao hơn và lượt xem nhiều hơn.

Vì tài liệu phần mềm chứa nhiều câu không hoàn chỉnh và phần tử mã, các thư viện xử lý ngôn ngữ tự nhiên có sẵn thường mắc lỗi. Tài liệu phần mềm viết bằng ngôn ngữ khác tiếng Anh còn khó phân tích hơn vì vẫn có xu hướng dùng tiếng Anh cho thuật ngữ kỹ thuật. Tức là, nó pha trộn hai ngôn ngữ tự nhiên và các phần tử mã. Cần kết hợp các heuristic ứng biến và kỹ thuật mô hình hóa nâng cao để xử lý những trường hợp như vậy.

Kết hợp các mảnh ghép lại giúp xây dựng được một công cụ nhận tên một mô-đun Python làm đầu vào và tạo ra các câu có ý nghĩa về mô-đun này từ các chuỗi thảo luận trên Stack Overflow. Xa hơn, Treude và cộng sự đã có thể sử dụng phụ thuộc ngữ pháp giữa các từ để tự động tìm tài liệu phần mềm giải thích cách thực hiện một tác vụ, rồi tự động xác định các đoạn mã có thể hoàn thành tác vụ đó.

Kết luận

Quá thường xuyên, những điều được tin rộng rãi về phát triển phần mềm dựa trên ý kiến mạnh và tiếng nói to hơn là bằng chứng. Như đã mô tả từ đầu, điều đó đang thay đổi khi hàng trăm nghiên cứu chất lượng cao xuất hiện mỗi năm để củng cố một số niềm tin, như "duyệt mã thực sự là cách tốt nhất để tìm lỗi", và thách thức những niềm tin khác, như "phát triển hướng kiểm thử không hiệu quả như một số người tin, và câu lệnh goto thực ra không gây hại".

"Kỹ thuật" được định nghĩa là "việc áp dụng phương pháp khoa học để tạo ra những thứ hữu ích". Nếu điều đó đúng, thì phát triển phần mềm có thể cuối cùng, nhờ khoa học dữ liệu, đang trên con đường trở thành một ngành kỹ thuật thực thụ. Nếu bạn muốn thấy các khóa học chỉ cho bạn cách áp dụng khoa học dữ liệu vào phát triển phần mềm, hãy cho chúng tôi biết.

Đọc thêm

Hằng năm, các nhà nghiên cứu trình bày hàng chục phát hiện mới trong lĩnh vực này tại các hội nghị như Mining Software Repositories. Một số kỷ yếu vẫn bị khóa sau các paywall học thuật, nhưng ngày càng nhiều nhà nghiên cứu cung cấp bản preprint.

Với những ai muốn có cái nhìn tổng quan, cuốn sách năm 2010 Making Software là một tuyển tập "đỉnh cao" những kết quả thú vị nhất của thời điểm đó. Bộ ba sách mới có tựa Perspectives on Data Science for Software Engineering, The Art and Science of Analyzing Software Data và Sharing Data and Models in Software Engineering bao quát rộng hơn và cập nhật hơn về các chủ đề tương tự, và riêng Derek Jones đang thực hiện một cuốn sách mới có tựa Empirical Software Engineering Using R.