The 20 Regex Patterns I Actually Use (After Mass-Deleting the Other 200)

# 20 Pola Regex yang Sebenarnya Saya Gunakan (Setelah Menghapus Massal 200 Lainnya)

Suatu ketika saya menulis regex 847 karakter untuk validasi email. Itu menghabiskan tiga jam hidup saya yang tidak akan pernah saya dapatkan kembali, lengkap dengan lookahead bersarang, pengecualian kelas karakter, dan cukup backslash untuk membuat mata saya berair. Saya sangat bangga dengan itu. Saya mempostingnya di Slack tim kami dengan pesan sombong "Ini menangani SEMUA kasus pinggiran".

Kemudian seseorang mengaitkan saya dengan RFC 5322.

Untuk mereka yang tidak tahu, RFC 5322 adalah spesifikasi resmi alamat email. Pola regex penuh yang sebenarnya yang memvalidasi setiap alamat email yang secara teknis legal lebih dari 6.000 karakter panjangnya. Ini mencakup hal-hal seperti komentar dalam tanda kurung, string yang dikutip dengan karakter yang di-escape, dan literal domain dalam tanda kurung siku. Secara teknis, `"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com` adalah alamat email yang valid sesuai spesifikasinya.

Saya menatap pola 847 karakter saya. Lalu ke RFC. Lalu kembali ke pola saya. Kemudian saya melakukan apa yang akan dilakukan developer yang masuk akal: saya menggantinya dengan `/.+@.+\..+/` dan melanjutkan hidup saya. Karena — tidak ada yang benar-benar menggunakan kasus pinggiran tersebut. Dan jika mereka melakukannya, mereka layak mendapatkan apa pun yang rusak.

Itu terjadi lima tahun lalu. Sejak itu, saya telah menulis ratusan pola regex. Saya telah mendebug regex yang membuat developer senior menangis. Saya telah mengoptimalkan pola yang menyebabkan penurunan kinerja di produksi. Dan melalui semua itu, saya telah belajar satu hal yang krusial: sebagian besar pola regex adalah sampah yang tidak akan pernah Anda butuhkan.

Perjalanan Saya dari Regex Maksimalis ke Minimalis

Saya dulu mengumpulkan pola regex seperti beberapa orang mengumpulkan perangko. Saya memiliki file `regex-library.js` yang besar dengan pola untuk semua yang bisa dibayangkan. Alamat IPv6 dengan ID zona. Nomor kartu kredit dengan validasi algoritma Luhn. URL yang menangani setiap protokol yang tidak jelas. Nomor jaminan sosial dengan validasi nomor area dari tahun 1930-an.

File tersebut memiliki 3.200 baris. Saya yakin saya sedang membangun sesuatu yang berharga—sebuah perpustakaan komprehensif yang akan menghemat waktu saya di setiap proyek. Saya bahkan mulai menulis dokumentasi untuk itu, lengkap dengan contoh dan tolok ukur kinerja.

Kemudian saya berganti pekerjaan.

Di perusahaan baru saya, saya mencoba mengimpor perpustakaan regex tercinta saya ke dalam basis kode kami. Arsitek senior melihatnya sekali selama tinjauan kode dan mengajukan pertanyaan sederhana: "Dari 200+ pola ini, yang mana yang sebenarnya telah Anda gunakan dalam enam bulan terakhir?"

Saya memeriksa file tersebut dengan penyorot. Dari lebih dari 200 pola, saya mungkin hanya menggunakan sekitar 15. Yang lainnya adalah pola "hanya untuk berjaga-jaga"—solusi yang mencari masalah. Pola yang saya tulis karena mereka menarik secara intelektual, bukan karena mereka menyelesaikan masalah nyata.

Itulah saat saya memulai pembersihan regex besar saya. Saya melalui setiap pola dan bertanya: "Apakah saya membutuhkannya dalam produksi? Bukan 'mungkin saya akan membutuhkannya suatu hari,' tetapi apakah saya benar-benar membutuhkannya?" Jika jawabannya tidak, itu dihapus. Tanpa ampun. Tidak ada pengecualian "tapi bagaimana jika".

File tersebut berkurang dari 3.200 baris menjadi 400. Kemudian menjadi 200. Kemudian menjadi sekitar 100 baris yang berisi 20 pola yang sebenarnya saya gunakan secara rutin. Dan Anda tahu apa? Saya tidak pernah sekalipun merindukan 180 pola lainnya. Bahkan sedikit pun.

Ketika Regex Hampir Menghancurkan API Kami

Izinkan saya memberi tahu Anda tentang insiden produksi terburuk yang pernah saya sebabkan dengan regex. Kami memiliki titik akhir API yang menerima konten yang dibuat pengguna—sebenarnya bidang catatan di mana pengguna dapat menulis apa pun yang mereka inginkan. Cukup sederhana, bukan?

Kecuali kami ingin mendeteksi dan menghubungkan otomatis URL dalam teks. Jadi saya menulis pola regex yang saya pikir cerdas yang akan mencocokkan URL sambil menghindari positif palsu. Itu memiliki lookahead untuk memeriksa protokol yang valid, kelas karakter untuk nama domain, nomor port opsional, segmen jalur, parameter kueri, dan pengidentifikasi fragmen. Itu indah. Itu komprehensif. Itu adalah kesalahan katastrofik.

Pola tersebut berfungsi dengan baik dalam pengujian. Saya melempar berbagai URL ke dalamnya, dan itu menanganinya dengan sempurna. Saya merasa cukup baik tentang diri saya ketika kami menerapkan ke produksi pada Jumat sore. (Ya, saya tahu. Jangan pernah menerapkan pada hari Jumat. Saya belajar pelajaran itu dengan cara yang sulit.)

Dalam waktu satu jam, waktu respons API kami berubah dari 50ms menjadi 30 detik. Kemudian terjadi timeout. Pemantauan kami menyala seperti pohon Natal. Pengguna mengeluh. Telepon saya berdering. Itu buruk.

Penyebabnya? Seorang pengguna telah menempelkan string panjang yang kebetulan mengandung pola yang memicu backtracking katastrofik dalam regex saya. Mesin regex mencoba setiap kombinasi kemungkinan pencocokan, dan dengan string input 5.000 karakter, itu berarti miliaran usaha. Setiap permintaan membuat satu inti CPU mencapai 100% selama lebih dari 30 detik sebelum timeout.

Kami segera melakukan rollback, dan saya menghabiskan akhir pekan untuk menulis ulang pola itu. Versi baru lebih sederhana, kurang "pintar," dan memiliki batas eksplisit pada pengulangan. Itu tidak menangkap semua format URL yang mungkin—itu menangkap 99,9% URL yang sebenarnya digunakan orang. Dan itu berjalan dalam mikrodetik, bukan detik.

Insiden itu mengajarkan saya sesuatu yang krusial: kompleksitas regex adalah liabilitas, bukan aset. Semakin canggih pola Anda, semakin besar kemungkinan itu akan menyakiti Anda di produksi. Pola sederhana yang menangani kasus umum hampir selalu lebih baik daripada pola kompleks yang menangani setiap kasus pinggiran.

Menjelaskan Apa yang Benar-Benar Penting

Setelah bertahun-tahun menulis regex dan belajar dari kesalahan saya, saya telah mengembangkan kerangka kerja sederhana untuk memutuskan pola mana yang layak dipertahankan. Ini berfokus pada tiga kriteria:

Menggunakan kriteria ini, sebagian besar pola tidak memenuhi syarat. Regex canggih untuk mem-parsing tanggal ISO 8601 dengan offset zona waktu dan nomor minggu? Gagal tes frekuensi—saya hanya membutuhkannya mungkin dua kali setahun, dan ketika saya melakukannya, saya bisa mencarinya. Pola untuk memvalidasi nomor rekening bank IBAN? Gagal tes keandalan—begitu kompleks sehingga saya tidak percaya diri untuk memeliharanya. Pola rekursif untuk mencocokkan tanda kurung bersarang? Gagal tes kinerja—itu adalah mimpi buruk backtracking yang menunggu untuk terjadi.

Sisa pola adalah yang sederhana, cepat, dan memecahkan masalah yang saya temui secara rutin. Mereka tidaklah pola paling menarik. Mereka tidak yang membuat Anda merasa pintar. Tetapi mereka adalah yang benar-benar penting.

Pola regex terbaik adalah pola yang dapat Anda pahami enam bulan kemudian pada pukul 2 pagi ketika produksi sedang down dan Anda mencoba mencari tahu mengapa input pengguna merusak validasi Anda.

20 Pola yang Selamat dari Pembersihan

Berikut adalah daftar lengkap pola regex yang sebenarnya saya gunakan, disusun berdasarkan kategori. Ini adalah yang selamat—pola yang membuktikan nilai mereka melalui penggunaan berulang dalam proyek nyata.