Apakah kode ilmiah suatu ranah yang cukup berbeda untuk mengabaikan standar pengkodean yang umum?

Akhir-akhir ini saya mencoba untuk membungkus pikiran saya tentang fakta berikut.

Di satu sisi, ada sejumlah pedoman dan standar pengkodean untuk apa yang dianggap sebagai "sehat", "bersih", "ditulis dengan baik" dan seterusnya kode. Lihat "Kode Bersih" yang tampaknya juga banyak dibahas di sini. Contoh aturan: metode 7 baris panjang dan 1 atau 2 tingkat indentasi. Kode yang tidak mengikuti entah bagaimana diharapkan mati karena rawatan yang buruk.

Di sisi lain, saya mulai bekerja dengan OpenCV, OpenCascade, VTK, dll. Ini kode ilmiah. Mereka memiliki metode 2 halaman (sen sendiri), OpenCascade memiliki metode atau pembagian kelas menjadi 10 file (tidak ada lelucon di sini), VTK kadang-kadang berantakan juga. Namun proyek-proyek ini berhasil, dikelola dan digunakan secara luas!

Di mana tangkapannya? Apakah kita diperbolehkan menulis kode ilmiah, matematika-berat sedemikian rupa sehingga berfungsi, dan kita dapat mempertahankannya? Apakah Anda satu set standar yang terpisah untuk proyek-proyek seperti itu, jika ada?

Mungkin menjadi pertanyaan yang naif, tetapi saya dalam apa yang tampaknya menjadi pemrograman batal mencoba membangun seperangkat aturan bagaimana melakukan dan tidak melakukan hal-hal, yang merupakan cara saya telah diajarkan untuk bekerja di sekolah menengah. Sejak saya lulus, saya hampir tidak memiliki dukungan pedoman dengan hal-hal yang harus saya lakukan, terutama pemrograman - tidak ada yang mengganggu untuk mengajarkan itu.

Apakah kode ilmiah suatu ranah yang cukup berbeda untuk mengabaikan standar pengkodean yang umum?

Tidak, tidak.

Kode penelitian sering kali "dibuang" dan ditulis oleh orang-orang yang bukan pengembang berdasarkan latar belakang, betapapun kuatnya kepercayaan akademis mereka. Beberapa kode penelitian yang saya tulis akan membuat saya menangis . Tapi berhasil!

Satu hal yang perlu dipertimbangkan adalah penjaga gerbang untuk proyek mendorong apa yang dimasukkan. Jika sebuah proyek besar dimulai sebagai proyek kode akademik / penelitian, berakhir bekerja, dan sekarang berantakan, seseorang harus mengambil inisiatif untuk memperbaikinya.

Dibutuhkan banyak pekerjaan untuk memperbaiki kode yang ada yang tidak menyebabkan masalah. Terutama jika itu sama sekali spesifik domain atau tidak memiliki tes. Anda akan melihat bahwa OpenCV memiliki panduan gaya yang sangat komprehensif, bahkan jika tidak sempurna. Menerapkan ini secara surut ke semua kode yang ada? Itu .. bukan untuk yang lemah hati.

Ini bahkan lebih sulit jika semua kode itu berfungsi. Karena itu tidak rusak. Mengapa memperbaikinya?

Namun proyek-proyek ini berhasil, dikelola dan digunakan secara luas!

Inilah jawabannya, dalam arti tertentu. Kode kerja masih berguna dan jadi lebih mungkin dipertahankan.

Mungkin berantakan, terutama pada awalnya. Beberapa proyek ini mungkin dimulai sebagai proyek satu kali yang "tidak perlu digunakan kembali dan dapat dibuang."

Juga pertimbangkan bahwa jika Anda menerapkan algoritma yang kompleks mungkin lebih masuk akal untuk memiliki metode yang lebih besar karena Anda (dan orang lain yang akrab dengan sisi ilmiah) secara konseptual dapat memahami algoritma dengan lebih baik. Pekerjaan tesis saya terkait dengan optimasi. Memiliki logika algoritma utama sebagai salah satu metode jauh lebih mudah dipahami daripada mencoba memecahkannya. Itu tentu saja melanggar aturan "7 baris per metode" tetapi itu juga berarti bahwa peneliti lain dapat melihat kode saya dan lebih cepat memahami modifikasi saya pada algoritma.

Jika implementasi ini disarikan dan dirancang dengan baik, transparansi ini akan hilang bagi yang bukan programmer .

Kepada sesama penjawab: Pertanyaan ini merujuk pada basis kode perpustakaan sumber terbuka untuk tugas intensif komputasi dalam satu atau lebih domain ilmiah. Pertanyaan ini bukan tentang kode sekali pakai. Harap jeda sejenak untuk memastikan Anda memahami setiap aspek yang disorot sebelum menulis jawaban.

Saya pikir orang sering memiliki ide ini bahwa semua proyek open source dimulai dengan, "hei saya punya ide bagus untuk perpustakaan yang akan sangat populer dan digunakan oleh ribuan / jutaan orang lain" dan kemudian setiap proyek terjadi seperti itu.

Kenyataannya adalah banyak proyek dimulai dan mati. Persentase proyek yang sangat kecil "berhasil" ke tingkat OpenCV atau VTK dll.

OpenCV dimulai sebagai proyek penelitian dari Intel. Wikipedia menggambarkannya sebagai bagian dari "serangkaian proyek." Rilis non-beta pertamanya adalah 2006, atau tujuh tahun setelah pertama kali dimulai. Saya menduga bahwa tujuan awalnya adalah rilis beta yang bermakna, bukan kode yang sempurna.

Selain itu, "kepemilikan" OpenCV telah berubah secara signifikan. Ini membuat standar berubah, kecuali semua pihak yang bertanggung jawab mengadopsi standar yang sama persis dan mempertahankannya selama proyek berlangsung.

Saya juga harus menunjukkan bahwa OpenCV ada selama beberapa tahun sebelum Agile Manifesto yang mendapatkan inspirasi dari Clean Code diterbitkan (dan VTK hampir 10). VTK dimulai 17 tahun sebelum penerbitan Kode Bersih (OpenCV "hanya" 9 tahun sebelumnya).

Ilmuwan bukan pengembang. Tugas mereka bukan menulis kode semata. Tugas mereka adalah memecahkan masalah, dan pemrograman hanyalah salah satu alat yang dapat mereka gunakan.

Sebagian besar kode perusahaan ditulis oleh — sebagaimana mereka menyebutnya sendiri — pengembang profesional berantakan. Sebagian besar kode ini tidak menggunakan pola desain atau menyalahgunakannya. Sebagian besar komentar adalah kandidat untuk TheDailyWTF . Jadi karena di industri kami sendiri, kami melihat hasil seperti itu dari orang-orang yang pekerjaannya menulis kode, apa yang Anda harapkan dari orang-orang yang pekerjaannya bukan menulis program?

Akan semua praktek sebuah aktual profesional Belajar pengembang selama karirnya manfaat ilmuwan? Benar. Apakah mungkin bagi setiap ilmuwan untuk menghabiskan lima hingga sepuluh tahun pengembangan perangkat lunak pembelajaran hidupnya? Mungkin tidak. Oleh karena itu, kualitas kodenya seperti apa adanya.

Faktor lain adalah budaya. Jika pasangan Anda tidak menulis kode bersih, mengapa Anda melakukannya? Karena tidak ada yang peduli, Anda tidak benar-benar ingin melakukan upaya ekstra.

Akhirnya, sebagian besar kode ilmiah memiliki umur yang relatif pendek. Anda menulis kode untuk penelitian tertentu, dan ketika penelitian dilakukan, Anda tidak menggunakan kembali kode tersebut. Setelah Anda memiliki kebiasaan ini, sulit untuk membuat perbedaan antara perpustakaan yang dapat digunakan kembali seperti yang Anda kutip dan kode yang dibuang.

Mengabaikan? Tidak. Pertimbangkan kembali dan sesuaikan? Yakin. Banyak kode ilmiah intensif matematika dan kinerja kritis. Hal-hal seperti overhead panggilan fungsi sebenarnya bisa menjadi masalah, jadi Anda mungkin berakhir dengan struktur yang lebih bersarang daripada yang Anda lihat di aplikasi komersial biasa. Itu tidak berarti Anda harus terjun lebih dulu ke dalam ribuan optimasi mikro. Anda harus tetap fokus pada memilih algoritma yang tepat, dan hanya melakukan optimasi yang efeknya dapat Anda ukur.

Beberapa perbedaannya jelas dan sepele. Pedoman pengkodean biasanya akan memanggil untuk memilih nama variabel yang bermakna dan nama huruf tunggal akan segera dicurigai. Aplikasi ilmiah masih menginginkan nama variabel yang bermakna, tetapi terkadang nama yang paling bermakna adalah satu huruf, merujuk pada variabel dalam persamaan yang sudah dikenal.

Semua jawaban yang ada telah membahas pertanyaan ini secara komprehensif. Namun, saya ingin menunjukkan apa antipode sebenarnya antara suka OpenCV, dll., Versus katakanlah, kode yang dikembangkan sesuai dengan praktik bisnis yang baik (Kode Lengkap, Kode Bersih, PADAT, dll.)

Secara umum, ada banyak manfaat bisnis untuk kode sumber menjadi KISS - "tetap sederhana, bodoh." Ada juga YAGNI terkait - "Kamu Tidak Akan Membutuhkannya".

Sayangnya, untuk perangkat lunak intensif komputasi dalam domain ilmiah, kode sumbernya jarang sederhana atau ramping .

Secara tradisional, OpenCV menderita dari kurangnya generalisasi (banyak duplikasi kode untuk mendukung opsi yang berbeda), sedangkan VTK menderita generalisasi yang berlebihan (template).

Pada hari-hari awal, bagian-bagian tertentu dari OpenCV awalnya dikembangkan dalam C. Kemudian, OpenCV mengadopsi C ++ API yang kita kenal sekarang. Beberapa algoritma ditulis ulang untuk memanfaatkan antarmuka C ++ (kelas dasar abstrak) dan templat C ++. Algoritma lain hanyalah pembungkus untuk kode C asli. Sisa kode ini dapat ditemukan tersebar di modul "imgproc".

OpenCV berisi banyak pemrograman SIMD (vektorisasi). Sampai saat ini, pemrograman SIMD di C ++ masih memerlukan penggunaan intrinsik (intel.com) , (arm.com) .

Intrinsik SIMD dibaca seperti bahasa assembly, kecuali bahwa kompilator menangani penugasan register variabel, dan kompiler diperbolehkan beberapa kebebasan untuk menukar urutan instruksi untuk keuntungan kinerja. Algoritma yang ditulis untuk menggunakan SIMD intrinsik memiliki biaya perawatan yang tinggi. Inilah alasan saya menyebutkan pertanyaan yang saya tanyakan sebelumnya - Biaya pemeliharaan basis kode pemrograman SIMD .

Seseorang yang tidak melakukan pemrograman SIMD dapat dengan mudah dituntun untuk percaya bahwa SIMD dapat dienkapsulasi secara elegan dan bahwa pemrograman SIMD tingkat rendah seharusnya tidak diperlukan lagi. Ini sebenarnya jauh dari kebenaran. Saya akan menantang siapa pun untuk mencoba mengimplementasikan algoritma yang berguna dalam SIMD (bukan fraktal) dan melihat kesulitan penggunaan dalam enkapsulasi yang diusulkan ini.

Di bawah ini adalah daftar panjang ide ketika saya mencoba menganalisis mengapa perangkat lunak komputasi tidak dapat KISS atau YAGNI. Namun, semua gagasan ini terlalu generalisasi, dan tampaknya tidak mendukung pengamatan di atas.

Faktor utama yang berkontribusi adalah:

• Kinerja perangkat lunak
• Kebutuhan untuk mendukung banyak opsi algoritma dan pengorbanan
• Kebutuhan untuk mendukung berbagai platform dan kompiler perangkat keras yang berbeda
  • Senyawa ini dengan masalah kinerja perangkat lunak - kinerja harus baik untuk banyak platform dan kompiler perangkat keras.
• Kurangnya modernisasi basis kode yang sedang berlangsung , karena kurangnya sumber daya, kurangnya orang yang berpengetahuan yang dapat meningkatkan kualitas kode tanpa mengorbankan faktor-faktor lain, dll.
  • Proyek open-source menderita tragedi milik bersama .
  • Proyek sumber terbuka yang menerima hibah harus memenuhi hasil kerja tertentu - kualitas kode biasanya bukan bagian dari itu.
  • Secara khusus, bahkan ada kekurangan orang yang memiliki pengetahuan yang dapat membuat atau menyarankan peningkatan kualitas kode tambahan . Ini adalah masalah "bola mata yang hilang" - banyak orang mendapat manfaat dari kode tersebut, tetapi hanya sedikit yang mengambil waktu untuk membaca kode tersebut.
• Tidak adanya gerbang kualitas kode seperti ulasan kode, pengujian unit, analisis statis, dll.
  • Untuk proyek skala besar, gerbang kualitas kode ini bukan hanya langkah manual - masing-masing akan memerlukan infrastruktur (sistem berbasis web, sistem uji unit, sistem otomasi pembuatan, dll.)

Beberapa faktor yang berkontribusi di atas adalah antipode dengan pengembangan perangkat lunak bisnis:

• Biasanya, perangkat lunak bisnis tidak perlu berurusan dengan throughput data yang sama dengan yang terlihat dalam perangkat lunak komputasi.
• Perangkat lunak bisnis dapat dikaitkan dengan sistem operasi tunggal dan arsitektur komputer.
• Perangkat lunak bisnis dapat menghemat dalam memutuskan fungsi apa yang akan dimasukkan. Bahkan, pengembangan perangkat lunak bisnis mendorong manajer untuk mengatakan tidak pada fitur baru kecuali ada kasus bisnis yang baik.
  • Pengguna perangkat lunak bisnis internal dapat dilatih untuk melakukan berbagai hal secara berbeda, menghindari perlunya melakukan perubahan kode.
  • Jika perangkat lunak bisnis komersial kehilangan satu pelanggan karena satu fitur yang hilang, tetapi memperoleh dua pelanggan baru karena peningkatan kesederhanaan dan kemudahan penggunaan (lihat "Paradox of Choice" ), secara keseluruhan itu adalah keuntungan bersih - itu adalah yang baik hal bahwa fitur yang satu ini tidak ada.
• Perangkat lunak bisnis didukung oleh aliran pendapatan berkelanjutan, sehingga ia mampu menghabiskan sebagian darinya pada modernisasi basis kode berkelanjutan.

Apakah kode ilmiah suatu ranah yang cukup berbeda untuk mengabaikan standar pengkodean yang umum?

Itu tergantung pada apa yang Anda sebut "standar pengkodean umum". Saya tidak akan menyebut ekstrim Agile "umum". Secara khusus, menganggap fungsi yang panjangnya delapan baris terlalu panjang, atau yang memiliki lebih dari dua tingkat lekukan menjadi terlalu rumit adalah standar konyol di bidang pemrograman numerik / ilmiah.

Fungsi matriks kali matriks sangat sederhana lebih dari tujuh baris dan memiliki tiga tingkat lekukan. Fungsi ini akan tumbuh menjadi jauh lebih kompleks daripada yang seharusnya diperhatikan tentang efisiensi. Ini adalah operasi yang umum sehingga efisiensi sangat penting. Memecahnya menjadi beberapa bagian adalah hal yang tidak ingin Anda lakukan. Dekomposisi matriks akan menjadi lebih kompleks.

Saya memutuskan untuk memposting ini sebagai jawaban baru karena itu perspektif yang sama sekali berbeda.

Mari kita lihat contoh kode yang saya anggap sebagai "kode bersih" dalam hal visi komputer dan pemahaman gambar:

https://github.com/opencv/opencv/blob/05b15943d6a42c99e5f921b7dbaa8323f3c042c6/modules/photo/src/seamless_cloning_impl.cpp

Bagi mereka yang akrab dengan MATLAB dan komputasi ilmiah, kode dalam C ++ hampir sama ringkasnya dengan kode MATLAB sebersih mungkin.

Sekarang kita harus bertanya, mengapa tidak seluruh basis kode perpustakaan (OpenCV dalam contoh ini) ditulis dengan standar yang sama dengan contoh kode ini?

Kita harus membuat stratifikasi basis kode perpustakaan ilmiah yang besar menjadi level abstraksi .

Pada level rendah , Anda benar-benar menerapkan kembali penambahan dan pengurangan. Atau, secara harfiah pemetaan ulang setiap operasi ke implementasi tercepat pada setiap platform.

https://github.com/opencv/opencv/blob/master/modules/core/src/hal_replacement.hpp

Tingkat menengah adalah tempat kita menemukan kode "paling kotor", di mana mungkin menghabiskan 80% - 90% waktu eksekusi CPU. (Demikian pula, mungkin 80% - 90% dari upaya pengembangan dihabiskan di tingkat menengah, jika kita menghitung secara terpisah upaya pengembangan perangkat lunak dari penelitian ilmiah.)

Pada tingkat tinggi , kami memiliki kode terbersih, yang ditulis oleh para peneliti.

Diperlukan keunggulan yang kuat dalam organisasi kode sumber untuk memastikan level ini tidak tercampur. Ini di luar standar pengkodean , lebih banyak berkaitan dengan pengelolaan sumber terbuka .

Misalnya, kadang-kadang keputusan dibuat untuk membagi satu proyek sumber terbuka menjadi dua. Anda tidak dapat mewujudkan semua ini dengan kode yang dikomit.