Acuan referensi untuk praktik terbaik perangkat lunak

14

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.

pengguna1915639
sumber
1
Apakah ini membantu: plosbiology.org/article/…
akid
Jika tujuan menambahkan referensi adalah untuk meyakinkan pembaca bahwa praktik yang lebih baik lebih baik, mungkin lebih masuk akal untuk menjelaskan mengapa mereka lebih baik secara langsung; sekadar memberikan referensi mungkin tidak terlalu persuasif. Ingatlah bahwa banyak dari hal-hal ini adalah umum dalam kursus teknik perangkat lunak sarjana, dapat ditemukan dalam buku teks standar, dan tidak harus penelitian mutakhir.
Kirill
Pengalaman saya adalah bahwa Anda membutuhkan motivasi dan referensi. Saya baru saja berbicara dengan rekan kerja kemarin (keduanya mempraktikkan ilmuwan) yang berpendapat bahwa metodologi pengujian ad hoc bekerja lebih baik (jawaban singkat: mereka tidak). Penting untuk mengungkapkan motivasi dalam hal metrik yang oleh ilmuwan komputasi tampaknya lebih diperhatikan: makalah dampak yang lebih tinggi lebih cepat, dan hasil yang lebih benar (lihat tautan tentang penelitian yang dapat direproduksi). Arahkan ke referensi karena orang-orang akan melawan Anda pada poin-poin ini dengan mengklaim bahwa tidak ada manfaat yang signifikan.
Geoff Oxberry
Dalam semua kemungkinan orang-orang yang akan memeriksa tesis saya akan menjadi profesor ilmu kimia atau bahan daripada ahli sains komputasi. Mereka mungkin akan memiliki beberapa pengalaman menulis kode tetapi mereka hampir pasti tidak akan melakukan pengkodean serius karena mereka adalah siswa atau post-docs awal sendiri. Yang saya butuhkan adalah sesuatu yang mengatakan, "Pada tahun PhD saya yang saya habiskan untuk ini, saya benar-benar melakukan sesuatu yang bermanfaat dan tidak hanya mengendur"
user1915639

Jawaban:

13

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.

Geoff Oxberry
sumber
Daftar bacaan "Software Carpentry" terlihat membantu.
user1915639
6

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

David Ketcheson
sumber
Saya jelas yang kedua referensi pertama :-) Ini informasi lengkapnya adalah Wolfgang Bangerth, Timo Heister Apa yang membuat perpustakaan perangkat lunak sumber terbuka komputasi berhasil? Sains & Penemuan Komputasi, vol. 6, artikel 015010 (18 halaman), 2013
Wolfgang Bangerth
-2

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 :)

internetscooter
sumber
1
Studi, pada kenyataannya, membandingkan strategi deteksi cacat seperti pengujian unit, pemrograman pasangan, melangkah melalui program dengan debugger, dan tinjauan kode formal dan menilai kemanjurannya. Anda benar bahwa setiap strategi memiliki tempatnya. Komunitas pengembangan perangkat lunak mengakui hal ini dalam literatur, dan menyarankan apa yang paling cocok untuk berbagai jenis proyek. Jika "terlalu banyak variabel dan faktor manusia" benar-benar merupakan hambatan untuk merumuskan praktik terbaik, kami tidak akan memilikinya dalam kedokteran, atau bidang lain dengan masalah rumit yang sama, namun kami melakukannya. Saya tidak membeli argumen Anda.
Geoff Oxberry
"a bubur pernyataan yang lebih kuat dalam PhD Anda" adalah kesalahan ketik yang indah
denis