Nhiều lập trình viên đang học Data Science để có thể phân tích được dữ liệu người dùng và họ ngày càng có xu hướng sử dụng những kỹ thuật đó để giải quyết những câu hỏi muôn thuở trong software development, như:

• Khi nào thì dự án bắt đầu.
• Cần test những yếu tố nào trong app.
• Ai nên sửa bug này?
• Phần nào của API khiến mọi người khó sử dụng nhất?

Đã có một sự bùng nổ về nghiên cứu thực nghiệm trong software engineering nhằm giải quyết những câu hỏi này trong suốt 15 năm qua, mà dữ liệu có sẵn nhiều nhất là ở trên các trang như GitHub và Stack Overflow. Bài blog này sẽ liệt kê sơ qua vài kết quả đại diện và đi vào chi tiết với ba phương pháp nổi bật nhất về cách sử dụng data science để giải quyết những khúc mắc trong một dự án phát triển phần mềm.

Data Science và Software Engineering: Một vài ví dụ

Cùng bắt đầu bằng những khám phá có tầm ảnh hưởng lớn đến giới Data Science của Yuan et al: những kỹ thuật test đơn giản có thể ngừa những lần sập hệ thống phân phối giàu data. Họ đã phân tích những thất bại ấy qua Cassandra, Hadoop MapReduce, cùng những hệ thống tương tự và thấy rằng:

• Hầu hết những sự cố đều cần tối đa 3 compute node để tái sản xuất (reproduce). Vậy nên, bạn thường không cần cluster để sửa cluster.

• Error logs thường chứa đủ dữ liệu để tái sản xuất.

• Phần lớn các lỗi nghiêm trọng có thể dễ dàng được ngăn chặn bằng cách thực hiện kiểm tra đơn giản bằng mã xử lý lỗi (error handling code).

Ý cuối cùng là khó lường trước nhất: Những chuyên gia thường hay test những dòng code phân tích (analysis code) khi mọi chuyện đều tốt đẹp nhưng rất ít khi test thử xem khi gặp lỗi, những dòng code đó có phát huy được hiệu quả hay không. Chỉ cần thêm vào vài lần test là có thể tránh khỏi nhiều lần downstream đáng tiếc.

Một kết quả quan trọng khác từ nghiên cứu của Altadmri và Brown khi quan sát 37 triệu nỗ lực compile program (biên dịch chương trình) của học sinh trung học nước Anh. Họ hỏi giáo viên của chúng về những lỗi thường gặp nhất và thấy rằng:

1. Những giáo viên thường không thống nhất với nhau về những lỗi mà học sinh có nguy cơ mắc phải.
2. Quan trọng hơn, những dự đoán của giáo viên có tương quan thấp so với những lỗi mà học sinh thật sự mắc phải. 

Dĩ nhiên, data mining (khai phá dữ liệu) không phải là cách duy nhất để tìm được những bằng chứng có cơ sở và có ích trong lập trình. Năm 2013, Andreas Stefik cùng team đã cho ra phần hai của tuyển tập những nghiên cứu về những vấn đề rằng liệu những ngôn ngữ này có dễ học hơn những ngôn ngữ còn lại hay không. Để kiểm chứng, họ đưa một ngôn ngữ lắp ghép (made-up language) vào nghiên cứu của họ với các từ khóa của ngôn ngữ ấy được tạo ra một cách ngẫu nhiên.

Họ ngạc nhiên rằng những ngôn ngữ “sử dụng ngoặc nhọn” như Java và Perl là rất khó tiếp cận đối với người mới và thường họ không nhận ra rằng đây là một ngôn ngữ ngẫu nhiên. Python, Ruby và cả Quorum thì dễ tiếp cận hơn nhiều vì có thể thực hiện A/B test cú pháp của mọi tính năng mới trước khi thêm vào.

Xác định những Security Bug Report (báo cáo lỗi bảo mật)

Fayola Peters tại LERO sử dụng mô hình dự đoán dựa trên văn bản để cho ra những bản báo cáo về security bugs trong các hệ thống theo dõi bug (bug trackers) của các hệ thống lớn nhằm mục đích ưu tiên nghiên cứu về vấn đề này. Trong một nghiên cứu, cô sử dụng data từ các dự án Chromium, Wicketm Ambari, Camel và Derby; nhưng chỉ có 0.8% là security bug reports trong số tổng số 45,940 bug reports.

Nhiều security bug thường được dán nhãn, và chúng có thể được sử dụng để các thuật toán phân loại (classifier) phát hiện những security bug khác chưa có nhãn. Bắt đầu bằng những kỹ thuật như Naïve Bayes và Random Forests (rừng ngẫu nhiên), nhưng hiệu năng của những mô hình chung (generic model) này có thể được cải tiến thông qua lọc những từ khóa chuyên biệt. Quan trọng nhất là kiểm tra xem rằng liệu những mô hình được xây dựng tốt với security bugs được dán nhãn có thể tìm được những bug tương tự trong các dự án khác hay không. Peters thấy rằng thuật toán phân loại (classifier) của cô đủ hữu ích để áp dụng vào thực tế, quả là một kết quả nghiên cứu tiềm năng. 

Patch (bản vá) của tôi có được chấp nhận?

Ở ví dụ thứ hai, các công ty luôn muốn có những sự điều chỉnh trong dự án để tránh phải tự duy trì các dòng code, còn các tình nguyện viên thì muốn biết liệu patch của họ có cơ hội hay không? Bởi vì thời gian giữa nộp và duyệt patch thường rất lâu, nên Bram Adams và nhóm của anh tại Polytechnique Montréal phải dựng những mô hình để dự đoán những patch nào được duyệt.

Cũng giống như các dự án về data science khác, dự án này bắt đầu bằng cách thu và dọn data từ nhiều nguồn, bao gồm các kho (repositories) Git và Gerrit code review. Tuy nhiên, với những dự án sử dụng review từ email, như kernel của Linux, thu thập data có nghĩa là loại bỏ lưu trữ danh sách gửi thư và sử dụng phương pháp suy nghiệm như giá trị tổng kiểm (checksum) các patch hoặc giao điểm dựa trên tập hợp của các dòng thay đổi để khớp các patch với các cuộc hội thoại (conversations). Ngay cả với sự trợ giúp của các công cụ như GrimoireLab, sẽ luôn có các patch được chia làm nhiều phần và review riêng. Trong Data Science, tùy thuộc vào nhà phân tích để xây dựng một mô hình và các giả định trong đó sẽ có tác động mạnh mẽ đến kết luận cuối cùng.

Bước thứ 2 để quyết định rằng phải sử dụng biến nào để kiểm nghiệm và những thang đo nào được sử dụng cho từng biến, như:

• Chất lượng patch
• Kinh nghiệm của người phát triển patch.
• Tiến trình đánh giá (ví dụ, đánh giá bình luận và số người đánh giá).
• Chất lượng đánh giá (ví dụ, cấp độ chi tiết của đánh giá).
• Thời gian đánh giá.
• Sự tương tác của người lập patch và người đánh giá (ví dụ, thân thiện hay tức giận).

Sáu điều này có thể sử dụng cho tất cả từ phân tích sống còn (Survival Statistics) đến phân tích quan điểm (Sentiment Analysis). Một khi đã quyết định được cần phải đo đạc gì, bạn có thể sử dụng công cụ Data Science của khóa học DataCamp. Bởi vì mục đích là để dự đoán được sự chấp nhận của patch trong tương lai nên hướng tiếp cận trực tiếp nhất là hồi quy logistic (logistic regression), nhưng vẫn còn nhiều cách khác.

Sau cùng, bạn có thể đo được mức độ quan trọng của biến để quyết định tầm ảnh hưởng của biến với mỗi patch được chấp nhận. Mục đích của bạn cuối cùng là xác định xem lập trình viên có thể làm gì để cải tiến những phần dư thừa nhằm bổ sung vào sản phẩm. Như thường lệ, bạn phải thật cẩn thận với hệ số tương quan nhân quả dễ nhầm lẫn, ngay cả một vài sự gợi ý đơn giản như: “ĐỪNG VIẾT IN HOA LỜI CAM KẾT CỦA BẠN” cũng có thể làm nên sự khác biệt.

Tìm kiếm sự giúp đỡ

Sự thay đổi lớn nhất trong cách làm việc của lập trình viên hơn 20 năm nay không phải về những ngôn ngữ mà họ sử dụng: mà là sự tin cậy trong việc hỏi và trả lời những câu hỏi trên Stack Overflow. Christoph Treude và cộng sự từ Đại học Adelaide đã phát triển nhiều phương pháp để làm tăng ích lợi của các trang web kiểu này.

Họ bắt đầu từ kết xuất cơ sở dữ liệu (data dump) của Stack Overflow. Sau khi hoàn thành vài thống kê khám phá về số lượng từ và câu, những từ thông dụng nhất, TF-IDF (term frequency-inverse document frequency), cứ thế, cho đến bước tiếp theo là xem thử những từ nào ở trong các chủ đề trên Stack Overflow (threads) đồng xuất hiện với những lượt vote cao hơn, tỉ lệ đồng thuận cao hơn và lượt view đếm được cao hơn. 

Bởi vì tài liệu về phần mềm chứa đựng nhiều câu không hoàn thiện và những nguyên tố về code, những thư viện có sẵn về xử lý ngôn ngữ tự nhiên (natural language processing). Tài liệu về phần mềm viết các ngôn ngữ khác tiếng Anh thậm chí còn khó phân tích hơn bởi vì nó vẫn phải sử dụng những thuật ngữ chuyên môn. Hay nói ngắn gọn, nó trộn lẫn giữa ngôn ngữ tự nhiên và các nguyên tố về code. Vậy nên, những kỹ thuật phỏng đoán và mô hình hóa cần phải được gom lại để giải quyết những trường hợp thế này.

Tất cả những điều này sẽ giúp xây dựng được một công cụ bằng cách sử dụng Python module như input để sản sinh ra nhiều câu có nghĩa về module này từ các chủ đề (threads) trên Stack Overflow. Đi sâu hơn, Treude và cộng sự đã có thể sử dụng sự phụ thuộc vào ngữ pháp giữa các từ để tự động tìm những tài liệu hướng dẫn thực hiện một công việc nào đó với phần mềm, và sau đó công cụ này sẽ tự động xác định được chính xác những mẫu cắt từ code (code snippet) để hoàn thành công việc mà người dùng tìm kiếm. 

Kết luận

Đáng buồn là, những sự thật rộng rãi về Software Development thường dựa trên các quan điểm và lời nói hơn là các bằng chứng. Như đã mô tả lúc đầu, nó được thay đổi khi mà hàng trăm cuộc nghiên cứu có chất lượng cao hàng năm luôn ủng hộ các niềm tin như “code review là cách tốt nhất để tìm bug”, và khiêu khích mọi thứ còn lại như “test-driven development không hiệu quả như mọi người thường tin, và các câu lệnh goto (goto statements) thường không hại lắm đâu”.

“Engineering” (kỹ thuật) được định nghĩa là “Sử dụng các ứng dụng của khoa học để tạo ra những thứ có ích”. Nếu đúng vậy thì cuối cùng, nhờ có Data Science, mà Software Development có thể đang dần trở thành một quy tắc kỹ thuật thực thụ. 

Để tìm hiểu thêm về sức mạnh của dữ liệu kết hợp cùng phát triển phần mềm. Bạn có thể đăng ký tham dự Tech Meetup Data Hub in Digital Transformation do VietnamWorks InTECH phối hợp cùng FPT Software tổ chức. Đây là hội thảo công nghệ hoàn toàn miễn phí, với diễn giả là các chuyên gia hàng đầu đến từ FPT Software. 

VietnamWorks InTECH
Theo Datacamp