Ada banyak pendapat kuat di seputar debat tapi jelas ini bukan soal pendapat, ini soal fakta . Jadi kita harus melihat penelitian empiris . Dan bukti dari itu jelas:
Ya , pengetikan statis sepadan dengan trade-off - dan tidak hanya sedikit, tetapi sebenarnya secara substansial . Faktanya, bukti kuat menunjukkan bahwa pengetikan statis dapat mengurangi jumlah bug dalam kode setidaknya 15% (dan ini adalah perkiraan rendah, persentase sebenarnya hampir pasti lebih besar). Itu adalah angka yang sangat tinggi : Saya pikir bahkan sebagian besar pendukung pengetikan statis tidak akan mengira bahwa itu membuat perbedaan yang drastis.
Pertimbangkan ini: jika seseorang mengatakan kepada Anda bahwa ada cara sederhana untuk mengurangi bug di proyek Anda sebesar 15% dalam semalam, itu harus menjadi no-brainer. 1 Ini hampir seperti peluru perak.
Bukti disajikan dalam makalah Untuk Mengetik atau Tidak Mengetik: Mengukur Bug yang Dapat Dideteksi dalam JavaScript oleh Zheng Gao, Christian Bird dan Earl T. Barr. Saya mendorong semua orang untuk membacanya, ini adalah makalah yang ditulis dengan baik yang menyajikan penelitian teladan.
Sulit untuk meringkas secara ringkas seberapa ketat penulis melakukan analisis mereka, tetapi inilah garis besar (sangat kasar):
TypeScript dan Flow adalah dua bahasa pemrograman berdasarkan JavaScript yang, meskipun tetap kompatibel, menambahkan petunjuk jenis dan pemeriksaan tipe statis. Ini memungkinkan penambahan kode yang ada berdasarkan jenis, dan kemudian ketik periksa.
Para peneliti mengumpulkan proyek Open Source yang ditulis dalam JavaScript dari GitHub, melihat laporan bug yang diselesaikan dan berusaha untuk mengurangi setiap bug yang dilaporkan menjadi sepotong kode yang akan ditangkap oleh pemeriksa tipe statis TypeScript atau Flow. Ini memungkinkan mereka untuk memperkirakan batas bawah persentase bug yang dapat diperbaiki dengan menggunakan pengetikan statis.
Para peneliti mengambil tindakan pencegahan ketat untuk memastikan bahwa analisis mereka tidak akan menganggap bug terkait non-tipe sebagai terkait dengan tipe. 2
Dibandingkan dengan studi sebelumnya, studi baru ini memiliki kekuatan khusus:
- Ada perbandingan langsung dari pengetikan statis vs dinamis, dengan beberapa (jika ada) faktor pembaur, karena satu-satunya perbedaan antara JavaScript dan TypeScript / Flow adalah pengetikan.
- Mereka melakukan replikasi di berbagai dimensi dengan memeriksa TypeScript dan Flow (yaitu sistem tipe yang berbeda), dan dengan meminta orang yang berbeda mereproduksi anotasi tipe (manual) untuk memperbaiki bug. Dan mereka melakukan ini di sejumlah besar basis kode dari berbagai proyek.
- Makalah ini mengukur dampak langsung dari pengetikan statis pada bug yang dapat diperbaiki (bukan kualitas yang lebih samar).
- Para penulis mendefinisikan model yang ketat tentang apa yang harus diukur, dan bagaimana, di muka. Lebih jauh lagi, deskripsi mereka sangat jelas dan memudahkan untuk menganalisis kekurangan (selalu bagus ketika sebuah makalah penelitian membuka diri terhadap serangan: jika tidak ada serangan yang berhasil merusak argumennya, maka hasilnya akan semakin kuat). 3
- Mereka melakukan analisis kekuatan yang tepat sehingga ukuran sampel mereka cukup, dan analisis statistik berikutnya kedap udara.
- Mereka terlalu konservatif untuk mengecualikan penjelasan yang membingungkan, dan hanya mengukur satu bagian yang bergerak. Selain itu, mereka membatasi analisis mereka untuk bug yang dapat segera diperbaiki dengan memasukkan jenis, dan mengecualikan apa pun yang mungkin memerlukan refactoring lebih lanjut untuk mengakomodasi pengetikan. Jadi pada kenyataannya, efeknya masuk akal jauh lebih besar, tetapi tentu saja tidak lebih kecil dari apa yang mereka laporkan.
- Dan akhirnya, mereka tidak menemukan sedikit efek tetapi perbedaan yang mengejutkan . Meskipun prosedurnya terlalu konservatif, bahkan pada akhir rendah dari interval kepercayaan 95% mereka menemukan bahwa ada setidaknya 10% bug yang akan hilang dengan cek tipe tambahan minimal.
Kecuali ada kesalahan mendasar pada makalah yang belum ditemukan siapa pun, makalah tersebut secara meyakinkan menunjukkan manfaat besar dari pengetikan statis, hampir tanpa biaya. 4
Pada catatan sejarah, penelitian tentang pengetikan disiplin dalam pemrograman telah memiliki awal yang sulit karena, untuk waktu yang lama, bukti tidak jelas sama sekali. Alasan untuk ini adalah bahwa melakukan percobaan sistematis untuk memeriksa efek dari pengetikan statis vs dinamis tidak mudah: percobaan sistematis harus mengisolasi efek yang kami selidiki. Dan sayangnya kita tidak dapat mengisolasi efek dari disiplin pengetikan, karena itu terkait dengan bahasa pemrograman.
Sebenarnya ada bahasa pemrograman yang memungkinkan pengetikan statis dan dinamis dalam dialek yang berbeda (mis. VB dengan Option Strict
On
atau Off
, atau Lisp yang diketik secara statis). Namun, ini tidak cocok untuk perbandingan langsung, yang paling penting karena tidak ada basis kode yang cukup besar yang memungkinkan perbandingan langsung. Paling-paling kita dapat membandingkannya dalam “pengaturan laboratorium”, di mana subjek uji secara acak menyelesaikan tugas dalam varian bahasa yang diketik secara statis atau dinamis.
Sayangnya tugas pemrograman buatan ini tidak memodelkan penggunaan dunia nyata dengan baik. Secara khusus, banyak dari mereka yang kecil cakupannya dan memecahkan masalah yang jelas yang dapat diringkas pada setengah halaman teks.
Untungnya itu di masa lalu, karena TypeScript, Flow dan JavaScript memang bahasa yang sama kecuali untuk pengetikan statis, dan karena ada set data dunia nyata yang luas dari kode dan bug untuk diambil sampelnya.
1 Terinspirasi oleh kutipan dari kertas aslinya.
2 Saya tidak sepenuhnya senang dengan ini: salah satu kekuatan utama dari bahasa yang diketik secara statis adalah bahwa masalah yang tampaknya tidak terkait tipe dapat diungkapkan dengan cara yang dapat diperiksa jenisnya secara statis. Ini mengubah banyak kesalahan logika menjadi kesalahan tipe, yang secara drastis meningkatkan tingkat bug yang dapat ditangkap oleh pengetikan statis. Bahkan, makalah ini secara kasar mengklasifikasikan bug yang tidak terkait jenis dan saya berpendapat bahwa sebagian besar dari mereka sebenarnya bisa ditangkap oleh pengetikan statis.
3 Saya mengundang siapa pun, terutama pendukung pengetikan dinamis, untuk mencoba menemukan kekurangan yang belum terselesaikan dalam analisis. Saya tidak berpikir ada banyak (jika ada), dan saya yakin bahwa tidak ada cacat potensial secara material akan mengubah hasilnya.
4 Saya menduga bahwa biaya aktual pengetikan statis dalam proyek berskala besar nyata tidak ada, karena kemudian menjadi bagian alami dari arsitektur dan bahkan mungkin menyederhanakan perencanaan. Memperbaiki kesalahan tipe statis membutuhkan waktu, tetapi jauh lebih sedikit daripada kesalahan yang ditemukan kemudian. Ini telah dipelajari secara empiris secara luas dan telah dikenal selama beberapa dekade (lihat misalnya Code Complete ).