Metodologi perangkat lunak mana yang harus saya ikuti ketika saya melakukan penelitian?

9

Saya biasanya menganalisis data percobaan dan meskipun saya memiliki skema umum tentang langkah-langkah yang perlu saya lakukan, saya mungkin perlu menyesuaikannya dengan spesifikasi percobaan atau pertanyaan di belakang. Saya biasanya satu-satunya pengkodean.

Saya melihat wikipedia tetapi saya tidak yakin metodologi mana yang dapat saya gunakan, sebagian karena saya belum pernah mengikuti, dan sebagian karena saya kadang-kadang hanya mengeksplorasi data, untuk melihat seperti apa tampilannya, dan kadang-kadang saya hanya ingin jawaban. (Dan karena saya tidak banyak diharapkan untuk menguji atau memiliki kualitas tertentu pada kode saya)

Saya diminta untuk mengajukan pertanyaan ini setelah satu atau dua jam menemukan bahwa fungsi r tablebergantung pada urutan vektor dan bukan pada nama elemen untuk membandingkannya. Maka saya pikir saya harus menguji perilaku dan fungsi di mana saya digunakan dengan beberapa data tiruan. Tapi saya menggunakan tabel setelah analisis lain menghasilkan kurangnya informasi, jadi saya tidak bisa mengikuti metodologi pengembangan yang digerakkan oleh tes (jika saya memahaminya dengan benar). Namun saya merasa bahwa dengan beberapa perbaikan dalam cara saya menghadapi proyek, saya bisa lebih efisien, selain mendeteksi kesalahan lebih cepat, tetapi juga bagaimana dan apa yang harus dicari jika saya meragukan hasilnya, jadi tolong jangan fokus hanya pada contoh kesalahan ini.

Metodologi perangkat lunak mana yang paling cocok dalam penelitian?

Saya pada dasarnya bertanya bagaimana cara memastikan kualitas dan kemajuan waktu serta menjaga kekhususan penelitian.

Contoh cara saya bekerja:

Seorang ahli biologi memikirkan pertanyaan dan tahu bahwa melakukan percobaan akan menghasilkan data yang menarik (yaitu, tingkat ekspresi gen dalam dua kondisi), kemudian dia mengatur percobaan dan mengingat kembali sampel dari 10 orang / tikus / tikus. Sekarang saya harus menganalisis data tersebut untuk 10 sampel menggunakan perpustakaan dan tes yang ada (atau melaksanakan tes baru) tetapi dengan mempertimbangkan pertanyaan yang ada dalam pikiran ahli biologi (yaitu gen mana yang lebih diekspresikan dalam satu kondisi daripada yang lain). Strukturnya sama dengan percobaan sebelumnya (yang melibatkan 6 kondisi dan hewan lain) tetapi uji statistik, normalisasi, struktur data dapat berubah. Jadi saya biasanya menyalin versi sebelumnya dan menyesuaikannya dengan kebutuhan saat ini.

llrs
sumber
7
apa yang kau dong sekarang baik-baik saja. Tidak ada metodologi yang akan menghentikan Anda melakukan kesalahan! hanya pastikan Anda menggunakan sistem kontrol versi dan menjaga basis kode Anda terorganisir dengan baik.
gbjbaanb
Tidak ada metodologi yang akan menghentikan kesalahan. Tetapi beberapa akan menangkap kesalahan lebih cepat! Desain berdasarkan kontrak, atau desain berdasarkan kontrak.
Frank Hileman
Bisakah Anda jelaskan kalimat terakhir Anda? Saya tidak mengerti sama sekali.
llrs
mungkin en.wikipedia.org/wiki/Test-driven_development dengan semacam kerangka uji otomatis - tes kecil berguna untuk menangkap bug dan tes yang lebih besar dapat memetakan (kurang-lebih) pada hipotesis Anda
david.libremone
1
@Lopis idealnya Anda menulis tes pertama, gagal, lalu menulis kode, tes lulus, lalu Anda mengkomit - jika Anda menemukan bug di kemudian hari, Anda menulis tes yang akan menangkap bug, gagal , perbaiki kode, tes lulus, lalu Anda komit kode Anda - Anda tidak dapat mengabaikan segalanya, tetapi Anda dapat memastikan hal yang sama tidak terjadi lagi
david.libremone

Jawaban:

6

Apa yang dibutuhkan mungkin bukan metodologi perangkat lunak, tetapi perubahan politik di dunia akademis yang memperbaiki masalah kurangnya pengakuan terhadap peran yang dimainkan oleh pengembangan perangkat lunak dalam sains.

The Software Keberlanjutan Institute (UK) adalah organisasi yang paling dekat dengan apa yang Anda cari: bagaimana untuk berdebat untuk penggunaan yang lebih teliti pemrograman komputer dalam penelitian ilmiah.

Ini juga menyediakan petunjuk informasi bagi mereka yang tertarik dengan metodologi pengembangan perangkat lunak.

Namun, saya harus menunjukkan bahwa metodologi biasanya mengatur tim pemrogram perangkat lunak, dengan iterasi dan penyempurnaan tujuan proyek secara bertahap, dan bekerja dengan basis kode yang stabil yang bertahan untuk waktu yang lama. Mereka untuk proyek yang urutan besarnya lebih kompleks daripada apa yang Anda lakukan.


Mengenai mengapa hal yang sangat jelas benar ini (penggunaan lebih hati-hati dari pemrograman komputer dalam penelitian ilmiah) belum tercapai dan selalu ditegakkan, inilah kebenaran yang tidak nyaman: dalam lingkungan administrasi akademik, para ilmuwan dapat terlihat menurunkan pentingnya bermain dengan komputer pemrograman. Kadang-kadang mereka dapat terlihat bersatu untuk menyangkal pengakuan kontribusi dari orang-orang yang terlibat dalam perangkat lunak, bahkan jika sifat kontribusi itu sesuai dengan disiplin ilmu.


Di tempat kerja Anda, ada hal-hal yang hilang, dan hal-hal yang dapat Anda lakukan.

Hal-hal yang hilang:

  • Kurangnya pedoman
  • Kurangnya pengawasan atau orang untuk bertanya
  • Kurangnya mentor atau pemrogram komputer yang memiliki pengetahuan dengan alat yang Anda gunakan (misalnya R)
  • Kurangnya penggunaan kembali perangkat lunak, arsip, kontrol versi, atau dokumentasi perangkat lunak yang dikembangkan sebelumnya, untuk pengulangan dan tujuan pembelajaran

Singkatnya, budaya secara keseluruhan adalah bahwa orang-orang yang terlibat tidak benar-benar tertarik pada ... Anda dapat menebaknya ... penggunaan yang lebih cermat dari pemrograman komputer dalam penelitian ilmiah.


Hal yang dapat Anda lakukan:

  • Luangkan lebih banyak waktu untuk mempelajari alat Anda.
    • Luangkan lebih banyak waktu membaca dokumentasi dan contoh kode untuk bahasa pemrograman Anda
    • Anda harus belajar mencintai alat yang Anda gunakan.
  • Cobalah untuk menuliskan sesuatu, untuk kepentingan programmer komputer berikutnya yang akan diperbudak ke kelompok orang yang sama selama beberapa tahun ke depan
    • Wiki akan sangat bagus.
  • Cobalah untuk mengatur kontrol versi sumber
    • Dapat mengambil cuplikan kode yang sering digunakan kembali
    • Dapat menyimpan cuplikan kode yang digunakan dalam percobaan tertentu

Untuk pengembang perangkat lunak karier, pedoman seperti ini dapat ditemukan di:

Ini dianggap sebagai persyaratan dasar untuk menjalankan bisnis pengembangan perangkat lunak. Namun, saat Anda berperang apatis, sendirian, Anda harus memprioritaskan. Menjadi lebih baik dengan alat-alat, menulis dan memelihara informasi, menjaga versi kode sumber adalah minimum untuk lingkungan tunggal.

rwong
sumber
Sumber daya yang menarik di Software Sustainability Institute, terima kasih! Saya akan menulis panduan saya sendiri tentang kode dan manajemen data, saya memang memiliki seorang supervisor tetapi dia tampaknya tidak memiliki "pengetahuan dengan alat-alat", saya menggunakan git, tetapi saya akan mencoba mengikuti saran Anda tentang dokumentasi
llrs
ha ya, wiki ... karena sudah mencoba beberapa, saya akan merekomendasikan dokuwiki.org/dokuwiki# di sini. Mudah untuk mengatur dan menyimpan dokumen sebagai file teks daripada dalam database. Saya menemukan itu adalah keseimbangan terbaik antara kemudahan pengaturan, kemudahan penggunaan dan keberlanjutan data.
Newtopian
Masalah-masalah dalam sains berbantuan komputer yang dijelaskan oleh @rwong ada di sebagian besar institut yang pernah saya kerjakan (fisika dan astronomi)
steffen
2

Jangan terlalu memusingkan metodologi, tetapi cobalah dan lebih fokus pada apa yang Anda butuhkan untuk melacak, persyaratan Anda, untuk pengembangan perangkat lunak itu sendiri.

Setelah melakukan kunjungan singkat dalam posisi yang relatif mirip dengan Anda di sini adalah apa yang dapat saya ambil dari pengalaman pribadi saya.

Ketepatan algoritma

Mungkin aspek yang paling penting, Anda harus dapat membuktikan bahwa perangkat lunak Anda melakukan apa yang dirancang untuk dilakukan. Di sini pengujian otomatis adalah sekutu terbaik Anda. Saya menyadari ini bisa sulit dilakukan tanpa set data yang tepat tetapi sebenarnya Anda harus membiasakan diri membuat set data Anda sendiri. Namun tujuan mereka agak berbeda, Anda tidak mencoba mengekstraksi tren dari data tetapi memastikan perangkat lunak menghasilkan hasil yang dapat diprediksi dan mengoreksi dari kumpulan data yang diketahui. Jadi untuk pengenalan pola, misalnya, Anda tidak perlu makeup genetik multi-pertunjukan, hanya beberapa baris teks yang cukup untuk memastikan algoritma mendeteksi pola.

Saya biasa membuat data untuk mewakili kasus sudut, kasus mustahil. Saya cenderung lebih fokus pada ekstrem daripada pada norma yang diharapkan. Sering kali saya dapat mengingat pengujian untuk sesuatu yang tidak mungkin hanya untuk melihat situasi ini muncul dalam kumpulan data aktual. Seandainya saya tidak diuji untuk itu saya tidak akan menempatkan deteksi kesalahan dan logging diperlukan untuk mengidentifikasi potensi korupsi atau kesalahan dalam set data. TDD sangat cocok untuk bagian ini meskipun membuat set tes yang baik adalah saya pikir lebih penting untuk terlepas apakah Anda melakukannya sebelum atau setelah kode aktual.

Versi

Terlalu sering bagian ini ditinggalkan. Skema versi yang baik untuk kode Anda dan paket / eksekusi yang dihasilkan akan sangat membantu menjaga kemajuan Anda. Untuk dapat memulihkan dengan tepat kode yang digunakan untuk membuat hasil yang sebelumnya diperoleh dapat membantu saat melacak bug atau perbedaan. Bercabang juga dapat membantu saat bereksperimen dengan berbagai pendekatan atau algoritma.

Pastikan Anda menandai kode yang digunakan dalam perhitungan aktual, Periksa versi semantik jika Anda perlu bantuan dalam memberi nama versi.

Pembuatan otomatis

Akibat wajar dari poin di atas. Pastikan Anda mengotomatiskan sebanyak mungkin proses membangun dan mengemas perangkat lunak Anda. Anda tidak perlu menjadi monty penuh, cukup membuatnya mudah untuk membuat sistem akhir dari sumber dan dependensi. Tujuannya di sini adalah untuk menghemat waktu Anda tetapi juga memiliki cara yang dapat direproduksi untuk menciptakan kembali perangkat lunak dari sumber, termasuk dependensi dan eksternal lainnya. Groovy, Maven, semut, Scons, cmake, hanyalah contoh kecil alat otomatisasi bangun dan sistem skrip yang dapat membantu.

Jika Anda ingin bekerja lebih keras, instal Jenkins atau teamcity atau sistem integrasi berkelanjutan lainnya. Bonus tambahan jika Anda harus memelihara beberapa server atau pekerja untuk komputasi terdistribusi. Sebagian besar sistem ini akan memiliki sarana untuk membantu dalam pemeliharaan. Plus, Anda akan dapat sepenuhnya mengotomatiskan pengujian berjalan sehingga Anda tidak perlu menunggu hasilnya sebelum melanjutkan, cukup komit dan terima email nanti. Saya memiliki sistem yang membutuhkan waktu berjam-jam untuk melewati set tes. Memasang otomatisasi ini adalah investasi terbaik di waktu saya. Terutama jika Anda sudah memiliki skrip untuk membangun semuanya.

Isolasi Lingkungan

Peneliti menghabiskan banyak waktu mengisolasi satu set kecil atau kecil variabel yang menarik dari sistem yang kompleks melalui protokol mereka. Ini juga harus diperluas ke praktik pengembangan perangkat lunak Anda. Anda juga dapat memeriksa kontainerisasi dengan Docker atau Vagrant. Ini akan memberi Anda kontrol yang lebih baik terhadap lingkungan tempat perangkat lunak dijalankan.

Anda tidak perlu memiliki tim besar sebelum ini berhasil, saya sendirian sebagian besar waktu tetapi sangat diuntungkan menempatkan ini. Ketenangan pikiran dan waktu yang dihematnya asalkan jauh melebihi biaya overhead yang harus saya tanggung.

Newtopian
sumber
Saya biasanya meninggalkan kode seperti ketika saya selesai dengan itu, jadi versi terbaru adalah yang digunakan untuk perhitungan, jadi saya mungkin perlu memperbaikinya. Juga tentang ketepatan algoritmik, bukankah seharusnya saya menganggap bahwa perpustakaan yang saya gunakan berfungsi dengan baik?
llrs
Anda bisa, meskipun saya sudah melakukan tes pada dependensi eksternal sebelumnya tapi itu jarang ... itu kode Anda sendiri yang harus Anda uji, apakah Anda menggunakan perpustakaan dengan benar? Apakah gagal redictably (kode Anda)? dll.
Newtopian
0
  1. Bisakah Anda menggunakan R? Itu untuk apa.

  2. Buat kode Anda sederhana . Gunakan keterbacaan, dan jangan khawatir tentang kinerja kecuali itu masalah. Ada metodologi untuk mencegah tim pemrogram menempatkan bug di kode masing-masing, bahkan jika tim itu satu orang.

  3. Yang mengatakan, coding disiplin super penting. Saya telah melihat kode dari ilmuwan dan ahli matematika tingkat lanjut yang sangat terlatih, dan itu mengerikan . Mereka benar-benar mengabaikan pemformatan. Mereka meremas kode bersama-sama seperti itu vakum. Nama variabel mereka benar-benar membingungkan. Mereka tidak menulis komentar, atau mereka menulis komentar yang tidak bisa dipahami, atau komentar mengatakan satu hal sementara kode mengatakan yang lain. Jangan lakukan itu. Selalu berpikir ke depan untuk perubahan di masa depan yang mungkin harus Anda atau orang lain lakukan.

Mike Dunlavey
sumber
1
Saya menggunakan R, harap kode saya cukup sederhana untuk menemukan bug yang bisa saya tulis dan kesalahan yang bisa saya lakukan. Saya mengikuti gaya pemformatan kode Google R, dan saya ingin berpikir bahwa komentar berguna untuk menjelaskan mengapa saya mengambil keputusan seperti itu dalam kode.
llrs
@Lopis: Kalau begitu saya katakan Anda berada di jalur yang benar.
Mike Dunlavey
@Lopop dalam pengembangan perangkat lunak berbasis tim, merupakan hal rutin bagi anggota tim untuk meminta orang lain meninjau kode, berdasarkan asumsi bahwa lebih banyak mata dapat menangkap lebih banyak kesalahan. Sayangnya, dalam situasi Anda tidak ada orang yang mengulas ulasan Anda, dan budaya kerahasiaan dalam penelitian akan mencegah Anda membiarkan orang lain (di luar izin tempat kerja Anda) meninjau kode Anda.
rwong
1
@rwong sebenarnya saya diizinkan sekarang untuk membagikan kode penelitian saya, jadi siapa pun bisa memeriksanya di github
llrs
@Lopis: Semua alasan untuk membuatnya mudah dibaca. Satu hal yang saya coba lakukan adalah memberikan tutorial yang sangat kecil (dalam komentar) tentang materi pelajaran, karena kemungkinan keahlian pembaca akan berbeda dari milik saya.
Mike Dunlavey