Pengaturcara Ruby baru-baru ini menemui pengubah suai regex berbahaya yang boleh merosakkan aplikasi secara senyap. Flag /o, yang diwarisi daripada Perl, menyebabkan pola regex dengan interpolasi pemboleh ubah dikompil hanya sekali sahaja dan mengabaikan perubahan pemboleh ubah pada masa hadapan. Tingkah laku ini mencipta pepijat halus yang sukar dikesan dan dinyahpepijat.
Kelakuan Pengubah Suai /o Ruby :
- Menyusun corak regex hanya pada pelaksanaan pertama sahaja
- Mengabaikan perubahan pembolehubah dalam pelaksanaan seterusnya
- Diwarisi daripada Perl 4 (1990an)
- Mencipta pepijat senyap apabila pembolehubah interpolasi berubah
- Ruby moden secara automatik mengoptimumkan penyusunan regex
Sifat Menipu /o
Pengubah suai /o kelihatan tidak berbahaya dalam dokumentasi Ruby, diterangkan sebagai mod interpolasi. Walau bagaimanapun, penamaan ini mengelirukan. Apabila anda menambah /o pada pola regex yang mengandungi pemboleh ubah, Ruby mengkompil pola tersebut hanya semasa pelaksanaan pertama dan menyimpannya dalam cache secara kekal. Sebarang perubahan seterusnya pada pemboleh ubah yang diinterpolasi diabaikan sepenuhnya.
Sebagai contoh, jika anda mempunyai pola seperti /admin@#{domain}/o dan pemboleh ubah domain berubah semasa pelaksanaan program, regex akan terus menggunakan nilai domain asal dari percubaan padanan pertama. Ini mencipta keadaan berbahaya di mana kod anda kelihatan berfungsi dengan betul tetapi gagal secara senyap apabila keadaan berubah.
Interpolasi: Proses memasukkan nilai pemboleh ubah ke dalam rentetan atau pola pada masa runtime.
Ciri Warisan Yang Melebihi Tujuannya
Pengubah suai /o bermula daripada Perl 4 pada tahun 1990-an, ketika objek regex yang dikompil tidak boleh disimpan secara langsung. Pada masa itu, pengoptimuman ini masuk akal atas sebab prestasi. Ruby dan Perl moden secara automatik mengoptimumkan kompilasi regex, menjadikan /o sebahagian besarnya tidak diperlukan.
Perbincangan komuniti mendedahkan bahawa dokumentasi Perl semasa pun memberi amaran terhadap penggunaan pengubah suai ini. Seorang pembangun menyatakan bahawa dokumentasi Perl kini menerangkan /o sebagai cara untuk berpura-pura mengoptimumkan kod anda, tetapi sebenarnya memperkenalkan pepijat. Ciri ini kekal dalam kedua-dua bahasa terutamanya untuk keserasian ke belakang, tetapi kehadirannya yang berterusan mencipta risiko berterusan untuk pembangun.
Mengapa Ini Mencipta Senjata Berbahaya
Pereka bahasa pengaturcaraan secara amnya cuba mengelakkan senjata berbahaya - ciri yang memudahkan pembangun secara tidak sengaja membahayakan kod mereka sendiri. Pengubah suai /o mewakili jenis ciri berbahaya ini dengan tepat. Tidak seperti isu prestasi yang boleh dikenal pasti dan diperbaiki oleh pakar, pengubah suai ini mencipta pepijat misteri yang boleh kekal tidak dikesan dalam sistem pengeluaran.
Ini adalah senjata berbahaya. Sesuatu bahasa sepatutnya berusaha untuk tidak menambah senjata berbahaya. Setiap senjata berbahaya yang anda sediakan, seseorang akan menembak kaki mereka sendiri dengannya, jadi itu adalah harga yang tinggi.
Masalah menjadi lebih teruk kerana pendekatan alternatif - mengekstrak pola regex secara manual ke dalam pemalar - adalah lebih selamat dan jelas. Apabila pembangun memerlukan pengoptimuman regex, mereka boleh mencipta objek regex yang dikompil secara eksplisit daripada bergantung pada tingkah laku caching tersembunyi.
Alternatif Yang Lebih Selamat kepada /o:
- Ekstrak corak regex ke dalam pemalar
- Gunakan
Regexp.new()untuk menyusun corak secara eksplisit - Bergantung kepada pengoptimuman regex automatik Ruby
- Simpan objek regex yang telah disusun dalam pembolehubah instance
- Elakkan interpolasi apabila nilai corak adalah statik
 |
|---|
Sebuah zeppelin yang diselubungi api melambangkan potensi kegagalan bencana yang boleh timbul daripada penggunaan pengubah suai regex /o yang berbahaya dalam pengaturcaraan Ruby |
Alternatif Yang Lebih Baik Wujud
Daripada menggunakan /o, pembangun sepatutnya mengekstrak pola regex yang kerap digunakan ke dalam pemalar atau mengkompilnya secara eksplisit sekali sahaja. Pendekatan ini menjadikan pengoptimuman kelihatan dalam kod dan menghalang kegagalan senyap yang boleh disebabkan oleh /o. Pengoptimuman regex automatik Ruby moden sering menghapuskan keperluan untuk pengoptimuman manual sepenuhnya.
Konsensus di kalangan pembangun berpengalaman adalah jelas: elakkan /o sepenuhnya. Faedah prestasi yang minimum jarang membenarkan sakit kepala penyahpepijatan yang ketara yang boleh diciptanya. Apabila pengoptimuman benar-benar diperlukan, pendekatan eksplisit memberikan kawalan dan kebolehselenggaraan yang lebih baik daripada ciri warisan ini.