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

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.

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.

• http://www.scientific-computing.com/news/news_story.php?news_id=2737
• https://news.ycombinator.com/item?id=10553837

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:

• The Joel Test: 12 Steps to Better Code oleh Joel Spolsky

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.

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.

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.