Acuan referensi untuk praktik terbaik perangkat lunak

Saat ini saya sedang menulis tesis PhD saya. Saya menghabiskan sebagian besar PhD saya membersihkan dan memperluas kode ilmiah yang ada, menerapkan praktik terbaik rekayasa perangkat lunak yang sebelumnya tidak digunakan, dan ingin menulis tentang ini dalam tesis saya. Daripada hanya mengatakan "Saya menambahkan tes unit", saya ingin dapat menulis sesuatu seperti ini:

J. Doe menemukan unit test pada tahun 1975 . Sebuah studi baru-baru ini oleh Bloggs et al menunjukkan bahwa unit test mengurangi kejadian kesalahan perangkat lunak sebesar 73% ... 234 unit test terpisah ditambahkan ke basis kode, dikelola oleh kerangka kerja xUnit yang dibuat oleh Timpkins et al.$^{[23]}$$^{[24]}$$^{[25]}$

Saya mencari referensi akademis yang dapat dicoba (lebih disukai artikel di jurnal peer-review di mana saya bisa mendapatkan DOI, BibTeX dll) untuk praktik terbaik rekayasa perangkat lunak yang diterima secara luas, khususnya:

• tes unit
• kontrol versi
• modularisasi / pemisahan masalah
• profiling kinerja / optimasi berdasarkan informasi profiling
• bug / pelacakan masalah

Saya mencari informasi tentang penemuan awal dan evaluasi efektivitas selanjutnya. Jika ada artikel ulasan yang mencantumkan semua hal ini di satu tempat, maka jauh lebih baik.

Buku Steve McConnell Code Complete, edisi ke-2 memiliki daftar pustaka yang luas membahas masalah-masalah ini dari sudut pandang pengembang perangkat lunak lebih dari ilmuwan komputasi. Buku ini mulai sedikit ketinggalan zaman, karena mendekati satu dekade, sehingga tidak mencakup metodologi pengujian yang lebih baru seperti pengembangan yang didorong oleh perilaku. Namun demikian, ini adalah hal yang paling dekat dengan artikel ulasan komprehensif tentang konstruksi perangkat lunak yang saya ketahui. Anda juga dapat mencari artikel di Perangkat Lunak IEEE.

Di sisi ilmu komputasi, saya pikir artikel terbaik mungkin adalah versi PLoS dari preprint arXiv DavidKetcheson yang dikutip pada "Praktik Terbaik untuk Komputasi Ilmiah". Saya mengatakan ini berasal dari latar belakang teknik, di mana lebih sedikit orang mengutip referensi arXiv atau memposting pracetak arXiv, dan dengan demikian, mengutip "artikel jurnal nyata" (mengesampingkan, tentu saja, semua masalah tentang penerbitan ilmiah yang sedang diperdebatkan saat ini) ) dipandang lebih menguntungkan (dan saya mendapat kesan itulah sebabnya para penulis memilih untuk menerbitkannya dalam jurnal).

Para penulis makalah PLoS yang saya dan DavidKetcheson kutip adalah bagian dari sebuah organisasi bernama Software Carpentry yang menggunakan "kamp pelatihan" (biasanya 2 hari) untuk mengajar para ilmuwan tentang beberapa praktik terbaik untuk pengembangan perangkat lunak dan keterampilan komputasi yang berguna bagi para ilmuwan (bukan hanya ilmuwan komputasi). Situs web Software Carpentry memiliki daftar pustaka yang luas terkait dengan pengembangan perangkat lunak dalam sains. Jika Anda tertarik pada masalah ini, saya mendorong Anda untuk menjangkau mereka; mereka selalu mencari lebih banyak pendukung praktik terbaik dalam pengembangan perangkat lunak untuk melakukan sukarela dalam berbagai kapasitas. ( Penafian : Saya sukarela dengan Software Carpentry.)

Pembenaran umum lainnya untuk terlibat dalam praktik terbaik pengembangan perangkat lunak adalah reproduktifitas. Victoria Stodden telah menyusun daftar panjang referensi penelitian yang dapat direproduksi yang mungkin menarik, tergantung pada apa yang ingin Anda katakan.

Saya tidak memiliki referensi untuk asal usul masing-masing ide / praktik ini. Tetapi di sini ada beberapa referensi yang sangat baru dan relevan:

• Apa yang membuat perpustakaan perangkat lunak sumber terbuka komputasi berhasil?
• Praktik Terbaik untuk Komputasi Ilmiah

IMHO saya akan sangat hati-hati mengutip "Praktik Terbaik" dalam konteks pendekatan yang terbukti secara ilmiah. Sebagian besar praktik berasal dari "apa yang tampaknya berhasil untuk serangkaian proyek oleh seseorang yang dianggap sebagai guru yang terlibat dalam proyek-proyek itu", dan bukan berasal dari pengujian ketat terhadap berbagai pendekatan. Ada terlalu banyak variabel dan faktor manusia dalam rekayasa perangkat lunak untuk menyatakan ada daftar rujukan "praktik terbaik" (misalnya praktik yang bekerja pada satu proyek akan benar-benar gagal pada yang lain).

Saya akan mendekatinya dengan menyatakan apa yang dibutuhkan proyek Anda, mengapa dibutuhkan dan menambahkan referensi ke metode yang digunakan dan mengapa Anda menggunakannya.

Saya juga akan cenderung melaporkan hasil yang dapat diukur daripada referensi untuk menyatakan maksud Anda. Misalnya, jika unit Anda menguji menemukan 100 bug, 10 di antaranya cukup serius untuk menimbulkan keraguan pada hasil yang dipublikasikan sebelumnya. Ini adalah pernyataan yang jauh lebih kuat untuk dimiliki dalam PhD Anda daripada pernyataan yang Anda tahu asal usul unit test.

sunting: (kesalahan ketik tetap) - Menjawab yang berikut - Saya sering memberikan membesarkan anak sebagai analogi dengan proyek perangkat lunak. Ada banyak metode dan cara teruji untuk membesarkan mereka, mencoba membesarkan anak-anak Anda dengan satu metode karena itu bekerja untuk rata-rata atau subsampel yang diuji, akan bekerja selama anak Anda sama dengan yang diuji. Lebih baik untuk mengetahui banyak metode dan menerapkan yang bekerja dalam instance Anda. Ya, pengujian unit dapat dibuktikan, tetapi menerapkannya berdasarkan itu saja dapat berarti proyek Anda terlambat ke pasar dan karena itu gagal adalah tujuannya (jika itu adalah tujuannya). Saya mengatakan bahwa menerapkan metode untuk mendapatkan hasil dan memberikan hasil dari hasil itu, menurut saya lebih baik dalam tesis, daripada mendaftar hal-hal yang Anda coba berdasarkan pada proyek lain - kecuali tentu saja topik tesis ini mengukur metodologi :)