En iyi yazılım uygulamaları için atıflar

Şu anda doktora tezimi yazıyorum. Doktora çalışmamın önemli bir bölümünü, daha önce kullanılmayan yazılım mühendisliği ile ilgili en iyi uygulamaları uygulayarak ve tezimde yazmak isteyen mevcut bilimsel kodları genişleterek harcadım. Sadece "Birim testleri ekledim" demek yerine, şöyle bir şey yazabilmek istiyorum:

J. Doe 1975'te birim testleri icat etti [ 23 ] . Bloggs ve ark. [ 24 ] tarafından yapılan yeni bir çalışma , birim testlerin yazılım hatası insidansını% 73 azalttığını göstermiştir ... Timpkins ve ark. [ 25 ] tarafından oluşturulan xUnit çerçevesi tarafından yönetilen kod tabanına 234 ayrı birim testi eklendi.$^{[23]}$$^{[24]}$$^{[25]}$

Özellikle yaygın olarak kabul edilen yazılım mühendisliği en iyi uygulamalarına atıfta bulunan akademik referanslar (tercihen DOI'leri, BibTeX'i alabileceğim hakemli dergilerde makaleler) arıyorum:

• birim testleri
• sürüm kontrolü
• endişelerin modülerleştirilmesi / ayrılması
• profil bilgisine dayalı performans profili / optimizasyonu
• hata / sorun izleme

Hem ilk buluş hakkında hem de sonraki etkinlik değerlendirmeleri hakkında bilgi arıyorum. Tüm bu şeyleri tek bir yerde listeleyen bir inceleme makalesi varsa, o zaman çok daha iyi.

Steve McConnell'in Code Complete, 2. baskısı , bu konuları bilgisayar bilimi uzmanlarından daha fazla yazılım geliştiricisi açısından tartışan kapsamlı bir kaynakçaya sahiptir. Kitap biraz eski olmaya başlıyor, çünkü on yaşına yaklaşıyor, bu yüzden davranış odaklı geliştirme gibi daha yeni test yöntemlerini kapsamıyor. Yine de, farkında olduğum yazılım yapımıyla ilgili kapsamlı bir inceleme makalesine en yakın şey. Ayrıca IEEE Yazılımında makaleler de arayabilirsiniz.

Şeylerin hesaplamalı bilim tarafında, bence en iyi makale muhtemelen DavidKetcheson'un "Bilimsel Hesaplama için En İyi Uygulamalar" bölümünde belirtilen arXiv ön baskısının PLoS versiyonudur . Bunun, daha az insanın arXiv referanslarını veya arXiv baskılarını yayınladığı ve dolayısıyla "gerçek bir dergi makalesini" (elbette şu anda tartışılan bilimsel yayıncılıkla ilgili tüm konuları bir kenara koyduğu) bir mühendislik geçmişinden geldiğini söylüyorum. ) daha olumlu bir şekilde incelenir (ve bu yazarların onu bir dergide yayınlamayı seçmesinin nedeni budur).

DavidKetcheson ve benim bahsettiğim PLoS makalesinin yazarları, yazılımcılara bazı en iyi uygulamalar ve bilim adamları için yararlı hesaplama becerileri hakkında bilgi vermek için (genellikle 2 gün) "eğitim kampları" koyan Yazılım Marangozluğu adlı bir örgütün parçasıyız. hesaplamalı bilim adamları). Yazılım Marangozluğu web sitesinde bilimde yazılım geliştirme ile ilgili kapsamlı bir kaynakça bulunmaktadır . Bu konularla ilgileniyorsanız, onlara ulaşmanızı öneririm; her zaman çeşitli kapasitelerde gönüllü olmak için yazılım geliştirmede en iyi uygulamaların daha fazla savunucusunu arıyorlar. ( Feragatname : Yazılım Marangozluğu ile gönüllü olarak çalışıyorum.)

Yazılım geliştirme en iyi uygulamalarına katılmanın bir diğer yaygın gerekçesi tekrarlanabilirliktir. Victoria Stodden, söylemek istediklerinize bağlı olarak ilgi çekici olabilecek uzun bir tekrarlanabilir araştırma referansları listesi hazırladı.

Bu fikirlerin / uygulamaların her birinin kaynağı için referanslarım yok. Ancak, bazı son zamanlarda, ilgili referanslar:

• Hesaplamalı açık kaynaklı yazılım kitaplıklarını başarılı yapan nedir?
• Bilimsel Hesaplama İçin En İyi Uygulamalar

IMHO Bilimsel olarak kanıtlanmış yaklaşımlar bağlamında "En İyi Uygulamalar" a atıfta bulunarak büyük özen göstereceğim. Uygulamaların çoğu, farklı yaklaşımların titiz bir şekilde test edilmesinden ziyade, "bu projelerde yer alan guru olarak algılanan biri tarafından bir dizi proje için işe yarayan şeyden" kaynaklanmaktadır. Yazılım mühendisliğinde, "en iyi uygulamaların" yeniden doldurulabilir bir listesi olduğunu belirtmek için çok fazla değişken ve insan faktörü vardır (örneğin, bir projede çalışan bir uygulama diğerinde tamamen başarısız olacaktır).

Projenize neye ihtiyaç duyulduğunu, neye ihtiyaç duyduğunu ve kullanılan yöntemlere referanslar ekleyerek neden kullandığınızı söyleyerek yaklaşacağım.

Ayrıca, amacınızı belirtmek için referanslar yerine ölçülebilir sonuçları bildirmeye eğilimliyim. Örneğin, birim testleriniz 100 hata ortaya çıkarsa, bunların 10'u daha önce yayınlanan sonuçtan şüphe edecek kadar ciddi. Bu, birim testlerin kökenini bildiğiniz bir ifadeden çok PhD'nizde bulunması çok daha güçlü bir ifadedir.

edit: (sabit yazım hatası) - Aşağıdaki cevaplama - Ben sık sık yazılım projeleri için bir benzetme olarak çocuk yetiştirme vermek. Çocukları ortalama veya test edilmiş bir alt örnek için çalıştığı için çocuğunuzu tek bir yöntemle yükseltmeye çalışmanın birçok yöntemi ve test edilmiş yolu vardır, çocuğunuz test edilenle aynı olduğu sürece çalışacaktır. Birçok yöntemi bilmek ve örneğinizde çalışan yöntemleri uygulamak daha iyidir. Evet birim testi kanıtlanabilir, ancak bunu tek başına uygulamak projenizin geç piyasaya çıkması ve dolayısıyla amacının başarısız olması anlamına gelebilir (eğer amaç bu ise). Bir sonuç elde etmek için bir yöntem uygulamak ve bu sonucun sonucunu vermek için, bence, bir tezde, diğer projelere dayanarak denediğiniz şeyleri listelemekten daha iyidir - tabii ki tezin konusu metodolojileri ölçmüyorsa :)