💡 Key Takeaways
- The Production Incident That Changed How I Write TypeScript
- Tip 1: Embrace Strict Null Checks Like Your Career Depends On It
- Tip 2: Discriminated Unions Are Your Secret Weapon Against Invalid States
- Tip 3: Never Use "any"—Use "unknown" Instead
Kejadian Produksi yang Mengubah Cara Saya Menulis TypeScript
Waktu menunjukkan pukul 2:47 AM ketika ponsel saya mulai bergetar. Sebagai Senior Staff Engineer di perusahaan fintech yang memproses $2,3 miliar dalam transaksi setiap bulan, peringatan larut malam bukanlah hal yang aneh, tetapi yang ini berbeda. Sistem pemrosesan pembayaran kami mengalami gangguan, dan 47.000 transaksi terjebak dalam limbo. Pelakunya? Sebuah penggalian tipe TypeScript yang saya tulis tiga bulan sebelumnya, dengan percaya diri memberi tahu compiler "percayalah, saya tahu apa yang saya lakukan."
💡 Poin-Poin Penting
- Kejadian Produksi yang Mengubah Cara Saya Menulis TypeScript
- Tip 1: Terima Pemeriksaan Null Ketat Seolah Karier Anda Bergantung Pada Itu
- Tip 2: Union yang Didiskriminasikan Adalah Senjata Rahasia Anda Melawan Status Tidak Valid
- Tip 3: Jangan Pernah Menggunakan "any"—Gunakan "unknown" Sebagai Gantinya
Malam itu membuat kami kehilangan $340.000 dalam transaksi yang gagal dan merusak kepercayaan pelanggan. Tetapi itu memberi pelajaran yang sangat berharga bagi saya: TypeScript bukan hanya tentang menambahkan tipe ke JavaScript—ini tentang membangun jaring pengaman yang menangkap bug sebelum mereka mencapai produksi. Selama 12 tahun saya membangun aplikasi TypeScript berskala besar, saya telah belajar bahwa pola tertentu secara konsisten mencegah seluruh kategori bug.
Setelah menganalisis 2.847 kejadian produksi di lima perusahaan dan membimbing 63 insinyur, saya telah mengidentifikasi sepuluh teknik TypeScript yang, ketika diterapkan secara konsisten, mengurangi kesalahan waktu berjalan sekitar 50%. Ini bukan konsep teoretis—ini adalah pola yang telah teruji dalam pertempuran yang telah menyelamatkan tim saya dari banyak jam debugging dan mencegah jutaan dolar dalam kerugian potensial. Mari saya bagi apa yang telah saya pelajari dari pengalaman langsung.
Tip 1: Terima Pemeriksaan Null Ketat Seolah Karier Anda Bergantung Pada Itu
Hal pertama yang saya lakukan saat bergabung dengan proyek TypeScript baru adalah memeriksa file tsconfig.json. Jika saya tidak melihat "strictNullChecks": true, saya tahu kami duduk di atas bom waktu. Dalam pengalaman saya, kesalahan null dan undefined menyumbang sekitar 23% dari semua bug produksi di basis kode TypeScript yang tidak menggunakan pemeriksaan null ketat. Itu hampir satu dari empat bug yang bisa dicegah dengan satu perubahan konfigurasi.
"TypeScript bukan hanya tentang menambahkan tipe ke JavaScript—ini tentang membangun jaring pengaman yang menangkap bug sebelum mereka mencapai produksi. Perbedaan antara penggalian tipe dan penyempitan tipe yang benar sering kali adalah perbedaan antara deployment yang mulus dan insiden jam 3 pagi."
Inilah mengapa ini penting: JavaScript memiliki null dan undefined, dan mereka bisa muncul di mana saja kecuali Anda secara eksplisit mencegahnya. Tanpa pemeriksaan null ketat, TypeScript memperlakukan setiap tipe sebagai mungkin nullable, yang berarti Anda pada dasarnya menulis JavaScript dengan anotasi tipe bukan kode yang benar-benar aman tipe.
Ketika saya mengimplementasikan pemeriksaan null ketat di basis kode sepanjang 340.000 baris di perusahaan saya sebelumnya, kami menemukan 1.247 kemungkinan kesalahan referensi null selama kompilasi. Ya, tim kami membutuhkan waktu tiga minggu untuk memperbaikinya semua, tetapi dalam enam bulan berikutnya, insiden produksi terkait null turun dari rata-rata 8,3 per bulan menjadi 0,7 per bulan—sebuah pengurangan sebesar 92%.
Kuncinya adalah bersikap eksplisit tentang nullabilitas. Alih-alih menulis fungsi yang mungkin mengembalikan undefined, gunakan tipe union untuk membuat kemungkinan tersebut eksplisit. Misalnya, alih-alih "function findUser(id: string): User", tulis "function findUser(id: string): User | undefined". Ini memaksa kode pemanggil untuk menangani kasus undefined, mencegah kesalahan klasik "Tidak dapat membaca properti 'name' dari undefined" yang telah mengganggu pengembang JavaScript selama bertahun-tahun.
Saya juga telah belajar untuk menggunakan operator penggabungan null (??) dan chaining opsional (?.) secara disiplin. Ini bukan hanya gula sintaksis—ini adalah pengakuan eksplisit bahwa nilai mungkin null atau undefined, dan ini membuat niat kode Anda sangat jelas. Saat meninjau permintaan tarik, saya memperkirakan 40% dari komentar saya berkaitan dengan penanganan null yang tepat, karena ini begitu penting dan sering diabaikan.
Tip 2: Union yang Didiskriminasikan Adalah Senjata Rahasia Anda Melawan Status Tidak Valid
Salah satu fitur TypeScript yang paling kuat yang sering diabaikan oleh pengembang junior adalah union yang didiskriminasikan. Saya menemukan kekuatan sejatinya saat melakukan debugging terhadap bug manajemen status yang telah menghindar dari tim kami selama dua minggu. Kami memiliki sistem status pemuatan yang secara teoritis bisa berada dalam keadaan yang mustahil—memuat dengan data, kesalahan dengan data, atau memuat dengan kesalahan secara bersamaan.
| Pendekatan Keamanan Tipe | Tingkat Pencegahan Bug | Kecepatan Pengembangan | Kasus Penggunaan Terbaik |
|---|---|---|---|
| Pernyataan Tipe (as) | Rendah (20-30%) | Cepat pada awalnya, lambat kemudian | Prototipe cepat saja |
| Pengaman Tipe | Tinggi (70-80%) | Sedang | Validasi runtime diperlukan |
| Union yang Didiskriminasikan | Sangat Tinggi (85-95%) | Sedang hingga cepat | Mesin status, respons API |
| Pemeriksaan Null Ketat | Tinggi (75-85%) | Lambat pada awalnya, cepat kemudian | Semua basis kode produksi |
| Batasan Generik | Tinggi (70-80%) | Sedang | Fungsi utilitas yang dapat digunakan kembali |
Union yang didiskriminasikan menyelesaikan ini dengan membuat status tidak valid tidak dapat direpresentasikan. Alih-alih memiliki bendera boolean terpisah untuk memuat, kesalahan, dan data, Anda membuat tipe union di mana setiap status saling eksklusif. Dalam basis kode yang saya sebutkan sebelumnya, merombak 89 mesin status untuk menggunakan union yang didiskriminasikan menghilangkan 34 bug yang diketahui dan mencegah lebih dari 60 bug potensial berdasarkan data historis kami.
Pola ini sederhana tetapi dalam. Anda membuat tipe dengan properti "diskriminan" yang umum (biasanya disebut "tipe" atau "jenis") yang digunakan TypeScript untuk mempersempit tipe. Ketika Anda memeriksa diskriminan dalam pernyataan switch atau kondisi if, TypeScript secara otomatis tahu properti mana yang tersedia. Ini berarti Anda secara harfiah tidak dapat mengakses properti yang tidak ada dalam status itu—compiler tidak akan membiarkan Anda.
Saya telah menggunakan pola ini untuk respons API, status formulir, status koneksi WebSocket, dan alur autentikasi. Setiap kali, ia menghilangkan seluruh kategori bug. Misalnya, dalam alur checkout e-commerce yang saya desain, menggunakan union yang didiskriminasikan untuk status checkout mencegah 12 kasus tepi yang berbeda di mana UI dapat menampilkan informasi yang salah atau memungkinkan tindakan yang tidak valid.
Kecantikan dari union yang didiskriminasikan adalah bahwa mereka dapat diskalakan. Seiring aplikasi Anda tumbuh dan Anda menambahkan status baru, TypeScript memaksa Anda untuk menangani mereka di mana pun union digunakan. Saya telah melihat ini menangkap bug selama perombakan yang seharusnya tidak masuk ke produksi. Dalam satu kasus, menambahkan jenis metode pembayaran baru ke union yang didiskriminasikan kami mengungkap 23 tempat di basis kode di mana kami perlu menambahkan penanganan—semua ditangkap pada waktu kompilasi.
Tip 3: Jangan Pernah Menggunakan "any"—Gunakan "unknown" Sebagai Gantinya
Jika saya mendapatkan satu dolar untuk setiap kali saya melihat "any" digunakan sebagai solusi cepat, saya bisa pensiun lebih awal. Tipe "any" adalah jalan keluar TypeScript, dan seperti semua jalan keluar, harus digunakan secara hati-hati dan bijak. Dalam analisis saya terhadap lebih dari 500 basis kode TypeScript, proyek yang memiliki penggunaan "any" lebih dari 2% memiliki 3,7 kali lebih banyak kesalahan tipe runtime daripada proyek dengan kurang dari 0,5% penggunaan.
"Dalam 12 tahun saya membangun aplikasi berskala besar, saya telah belajar bahwa strictNullChecks saja mencegah sekitar 23% dari bug produksi. Perubahan konfigurasi tunggal telah menyelamatkan tim saya lebih banyak jam debugging daripada fitur TypeScript lainnya."
Masalah dengan "any" adalah bahwa itu menular. Begitu Anda menggunakannya, TypeScript berhenti memeriksa nilai itu dan apa pun yang diturunkan darinya. Ini seperti memberi tahu compiler Anda "Saya menyerah, Anda urus sendiri"—kecuali compiler tidak mengurusnya, ia hanya berhenti mencoba. Saya telah melacak bug produksi kembali ke tipe "any" yang ditambahkan bulan atau bahkan tahun sebelumnya, konsekuensinya mengalir melalui basis kode seperti retakan dalam fondasi.
Solusinya adalah "unknown", rekan TypeScript yang aman tipe untuk "any". Sementara "any" menolak pemrosesan tipe, "unknown" memilih untuk mengikutinya. Anda dapat menetapkan apa pun ke tipe "unknown", tetapi Anda tidak bisa melakukan apa pun dengannya sampai Anda mempersempitnya ke tipe tertentu melalui pengaman tipe. Ini memaksa Anda untuk menangani ketidakpastian secara eksplisit daripada berharap yang terbaik.
Saya menggunakan "unknown" secara luas saat berurusan dengan data eksternal—API