Pek çok yazılım geliştirici, müşterilerinin verilerini analiz etmek için veri bilimi öğreniyor. Giderek daha fazlası ise aynı teknikleri kendi sorularını yanıtlamak için de kullanabileceklerini fark ediyor. Örneğin:
- Bu proje ne zaman sevkiyata hazır olacak?
- Uygulamamızın hangi bileşenlerinin teste en çok ihtiyacı var?
- Bu hatayı kim düzeltmeli?
- API’min hangi kısımlarını insanlar kullanmakta en çok zorlanıyor?
Son 15 yılda, GitHub ve Stack Overflow gibi sitelerdeki verilerin erişilebilirliğinin de etkisiyle, bu soruları araştırmak üzere yazılım mühendisliğinde ampirik araştırmalarda bir patlama yaşandı. Bu blog yazısı birkaç temsilî sonucu sunuyor ve ardından üç tanesinin arkasındaki yöntemleri daha ayrıntılı olarak inceliyor.
Veri bilimiyle kendi projelerinizde bu tür içgörüler elde etmeyi nasıl öğrenebileceğinizi merak ediyorsanız, lütfen bana bildirin.
Veri Bilimi ve Yazılım Mühendisliği: Örnekler
Ölçekli veri bilimi yapan herkesi etkileyen bir bulgu ile başlayalım: basit testlerin dağıtık, veri yoğun sistemlerdeki kritik hataların çoğunu önleyebileceğine dair Yuan ve arkadaşlarının keşfi. Cassandra, Hadoop MapReduce ve benzeri sistemlerdeki hataları incelediler ve şu sonuçlara ulaştılar:
- Neredeyse tüm hatalar yeniden üretmek için 3 veya daha az hesaplama düğümü gerektiriyordu. Yani bir kümedeki hatayı ayıklamak için genellikle bir kümeye ihtiyacınız yoktur.
- Hata günlükleri, yeniden üretimi mümkün kılacak kadar veri içeriyordu.
- Yıkıcı hataların çoğu, hata işleme kodu üzerinde basit testler yapılarak kolaylıkla önlenebilirdi.
Son nokta en beklenmedik olanı. Profesyoneller genellikle işler yolunda giderken analiz kodlarının çalıştığını test eder, ancak bir şeyler ters gittiğinde doğru şeyi yaptığını nadiren sınar. Geliştirme sırasında bu tür birkaç test eklemek, aşağı akışta pek çok acıyı önleyebilir.
Bir diğer büyük ölçekli sonuç da Birleşik Krallık’ta lise öğrencileri tarafından yapılan 37 milyon program derleme girişimini inceleyen Altadmri ve Brown’ın çalışmasından geliyor. Öğretmenlere öğrencilerinin en yaygın hatalarının ne olduğunu sordular ve şu bulguları elde ettiler:
- Öğretmenler, öğrencilerin en olası hangi hataları yapacağı konusunda birbirleriyle hemfikir değildi.
- Daha da önemlisi, öğretmenlerin öngörüleri, öğrencilerin gerçekte yaptıkları hatalarla sadece zayıf bir korelasyon gösteriyordu.
Elbette, programlamada faydalı, kanıta dayalı içgörüler üretmenin tek yolu veri madenciliği değildir. 2013 yılında, Andreas Stefik’in ekibi, bazı dillerin diğerlerine göre öğrenmesinin daha kolay olup olmadığını inceleyen bir dizi çalışmanın ikincisini yayımladı. Karşılaştırma amacıyla, anahtar sözcükleri rastgele üretilmiş uydurma bir dili de çalışmaya dahil ettiler.
Şaşırtıcı bir şekilde, Java ve Perl gibi süslü parantezli diller, acemilerin tanımayı öğrenmesi açısından rastgele üretilmiş bir dil kadar zordu. Python ve Ruby öğrenmesi belirgin şekilde daha kolaydı ve her yeni özelliğin sözdizimini eklemeden önce A/B test eden Quorum daha da kolaydı. Andreas bu sonucu ve programlama dili tasarımcılarının kullanılabilirliğe neden bu kadar az önem verdiğini bu eğlenceli podcast’te tartışıyor.
Güvenlik Hata Kayıtlarını Belirleme
Bu çalışmaların nasıl yapıldığına bir örnek olarak, Fayola Peters LERO’da, büyük sistemlerin hata takipçilerinde güvenlik hatalarına ilişkin kayıtları bulmak ve böylece bunlar üzerindeki çalışmayı önceliklendirmek için metin tabanlı tahmin modelleri kullandı. Bir çalışmada Chromium, Wicket, Ambari, Camel ve Derby projelerinin verilerini kullandı; toplam 45.940 hata kaydı içeriyorlar ancak bunların yalnızca %0,8’i güvenlik hatası kaydı.
Bazı güvenlik hataları elle etiketlenmiştir ve bunlar, etiketlenmemiş olanları tespit etmek için sınıflandırıcıları eğitmekte kullanılabilir. Naïve Bayes ve Random Forest gibi teknikler bir başlangıç noktasıdır, ancak genel modellerin verimliliği çoğu zaman belirli anahtar sözcüklerin filtrelenmesiyle artırılabilir. En önemli kontrol, güvenlik hataları etiketli projelerden oluşturulan modellerin diğer projelerde benzer hataları ne kadar iyi bulabildiğidir. Sonuçlar cesaret vericiydi: Peters, sınıflandırıcılarının pratikte faydalı olacak kadar iyi çalıştığını gördü.
Yamam Kabul Edilecek mi?
İkinci bir örnek olarak, şirketler, kodu kendileri sürdürmek zorunda kalmamak için yaptıkları değişikliklerin projelere dahil edilmesini ister ve gönüllüler de yamalarının bir şansı olup olmadığına dair bir fikir edinmek ister. Yama gönderimi ile kabulü arasında genellikle uzun bir süre olduğundan, Bram Adams ve Montréal Polytechnique’teki grubu, hangilerinin kabul edileceğini tahmin etmek için modeller geliştiriyor.
Pek çok veri bilimi projesinde olduğu gibi, bu da Git depoları ve Gerrit kod incelemeleri dahil olmak üzere birden fazla kaynaktan veri alma ve temizleme ile başlıyor. Ancak Linux çekirdeği gibi e-posta tabanlı inceleme kullanan projelerde veri toplamak, posta listesi arşivlerini kazımayı ve yamaları tartışmalarla eşleştirmek için yama sağlama toplamları veya değişen satırların kümeye dayalı kesişimi gibi sezgisel yöntemleri kullanmayı gerektiriyor. GrimoireLab gibi araçların yardımıyla bile, birden çok sürümü incelenen yamalar ve ayrı ayrı incelenen birden fazla parçaya bölünmüş yamalar her zaman olacaktır. Tüm veri biliminde olduğu gibi, bir modeli inşa etmek analistin sorumluluğundadır ve modeldeki varsayımlar nihai sonuçlar üzerinde güçlü bir etki yapacaktır.
İkinci adım, hangi değişkenlerin inceleneceğine ve her biri için hangi ölçütün kullanılacağına karar vermektir. Örneğin:
- yama kalitesi
- yama geliştiricisinin deneyimi
- inceleme süreci (örneğin, inceleme yorumları ve inceleyen sayısı)
- inceleme kalitesi (örneğin, incelemelerin ayrıntı derecesi)
- inceleme süresi
- yama yazarı ile inceleyenlerin etkileşimi (örneğin, yapıcı mı öfkeli mi)
Yalnızca bu altı kalem bile sağkalım istatistiklerinden duygu analizine kadar her şeyi gerektirebilir. Ne ölçüleceğine karar verdikten sonra, DataCamp’in kurslarında öğretilen veri bilimi araçlarını uygulayabilirsiniz. Asıl hedefiniz gelecekteki yamaların kabulünü tahmin etmek olduğundan, en yalın yaklaşım lojistik regresyondur, ancak başka pek çok yöntem de vardır.
Son olarak, her değişkenin yama kabulüne etkisini belirlemek için değişken önemini ölçebilirsiniz. Bu kaçınılmaz olarak kısmen nitel olacaktır; çünkü amacınız, geliştiricilerin çalışmalarının ürüne girme olasılığını artırmak için neler yapabileceklerini belirlemektir. Her zamanki gibi, korelasyon ile nedenselliği karıştırmamaya dikkat etmek gerekir; ancak birkaç basit öneri bile (örneğin, "TAHHÜT MESAJLARINIZDA TAMAMEN BÜYÜK HARF KULLANMAYIN") gerçek bir fark yaratabilir.
Yardım Bulma
Son 20 yılda programcıların çalışma biçimindeki en büyük değişim, kullandıkları dillerde değil; soru sormak ve yanıt almak için neredeyse evrensel olarak Stack Overflow’a güvenmeleri oldu. Adelaide Üniversitesi’nden Christoph Treude ve işbirlikçileri, bu tür siteleri daha faydalı hale getirmek için yöntemler geliştiriyor.
Başlangıç noktaları Stack Overflow veri dökümü. Sözcük ve cümle sayısı, en yaygın sözcükler, terim sıklığı–ters belge sıklığı (TF-IDF) ve benzeri bazı keşifsel istatistikler yapıldıktan sonra, bir sonraki adım Stack Overflow başlıklarında hangi sözcüklerin daha yüksek oylar, daha yüksek kabul oranları ve daha yüksek görüntüleme sayılarıyla birlikte göründüğüne bakmaktır.
Yazılım dokümantasyonu pek çok eksik cümle ve kod öğesi içerdiğinden, hazır doğal dil işleme kütüphaneleri sıklıkla yanılır. İngilizce dışındaki dillerde yazılmış yazılım dokümantasyonunu ayrıştırmak daha da zordur; çünkü teknik terimler için yine de İngilizce kullanma eğilimindedir. Yani iki doğal dili ve kod öğelerini karıştırır. Bu tür durumları ele almak için geçici sezgisel yöntemler ile daha gelişmiş modelleme tekniklerinin birlikte kullanılması gerekir.
Parçaları bir araya getirmek, girdi olarak bir Python modülünün adını alıp Stack Overflow başlıklarından bu modül hakkında anlamlı cümleler üreten bir araç oluşturmayı mümkün kılar. Bir adım daha ileri giderek, Treude ve işbirlikçileri sözcükler arasındaki dilbilgisel bağımlılıkları kullanarak bir görevin nasıl yapılacağını açıklayan yazılım dokümantasyonunu otomatik olarak bulmayı ve ardından bu görevi yerine getirebilecek kod parçacıklarını otomatik olarak tanımlamayı başardılar.
Sonuç
Çok sık, yazılım geliştirme hakkında yaygın olarak kabul gören doğrular, kanıtlardan ziyade güçlü fikirler ve yüksek seslerle şekilleniyor. Başta anlatıldığı gibi, her yıl yüzlerce yüksek kaliteli çalışma yayımlanmasıyla bu durum değişiyor; bazı inançları destekliyor (örneğin, "kod inceleme gerçekten de hataları bulmanın en iyi yoludur") ve bazılarına meydan okuyor (örneğin, "test güdümlü geliştirme bazı insanların düşündüğü kadar etkili değildir ve goto deyimleri aslında zararlı değildir").
"Mühendislik", "bilimsel yöntemin faydalı şeyler yaratmak için uygulanması" olarak tanımlanmıştır. Bu doğruysa, yazılım geliştirme nihayet veri bilimi sayesinde gerçek bir mühendislik disiplinine dönüşme yolunda olabilir. Veri biliminin yazılım geliştirmeye nasıl uygulanacağını gösteren kurslar görmek isterseniz, lütfen bize bildirin.
İleri Okuma
Bu alanda araştırmacılar her yıl Mining Software Repositories gibi konferanslarda onlarca yeni bulgu sunuyor. Bu bildirilerin bir kısmı hâlâ akademik ücretli duvarların arkasında olsa da, giderek daha fazla araştırmacı ön baskılarını erişime açıyor.
Genel bir bakış arayanlar için, 2010 tarihli Making Software kitabı, o dönemin en ilginç sonuçlarından oluşan bir "en iyiler" derlemesiydi. Perspectives on Data Science for Software Engineering, The Art and Science of Analyzing Software Data ve Sharing Data and Models in Software Engineering adlı yeni bir üçleme ise aynı konuları daha geniş ve güncel biçimde ele alıyor; ayrıca Derek Jones, Empirical Software Engineering Using R adlı yeni bir kitap üzerinde çalışıyor.
