Daftar Periksa Tinjau Kode yang Saya Bangun Setelah 2.000 Permintaan Tarik

Saya mengkategorikan 2.147 komentar PR yang saya tinggalkan selama 18 bulan. 34% terkait dengan penanganan kesalahan. 22% terkait dengan penamaan. Hanya 8% tentang kinerja. Ini bukan yang saya harapkan ketika saya mulai melacak tinjauan saya. Saya pikir saya akan menangkap masalah arsitektur dan bug kompleks. Sebaliknya, saya terus-menerus menunjukkan masalah mendasar yang sama: pemeriksaan null yang hilang, nama variabel yang samar, dan pesan kesalahan yang tidak memberikan informasi berguna kepada pengguna. Setelah melihat masalah yang sama muncul dalam insiden produksi, saya menyadari bahwa ini bukan masalah sepele—ini adalah perbedaan antara sistem yang gagal dengan baik dan sistem yang membangunkan Anda pada jam 3 pagi.

Mengapa Sebagian Besar Daftar Periksa Tinjau Kode Kehilangan Esensi

Semua orang memberi tahu Anda untuk memeriksa gaya kode, cakupan tes, dan dokumentasi. Itu baik-baik saja, tetapi bukan di mana produksi rusak. Daftar periksa yang saya lihat dibagikan di blog teknik berfokus pada apa yang mudah diukur daripada apa yang sebenarnya penting. Mereka akan memberi tahu Anda untuk memverifikasi bahwa fungsi di bawah 50 baris, tetapi mereka tidak akan memberi tahu Anda untuk memeriksa apakah penanganan kesalahan benar-benar membantu seseorang untuk melakukan debug masalah pada jam 2 pagi ketika log adalah satu-satunya teman Anda.

Tinjauan kode terbaik tidak hanya mencegah bug—mereka mencegah jenis bug yang berubah menjadi insiden. Pemeriksaan null yang hilang bukan hanya potensi kegagalan; itu adalah potensi peristiwa korupsi data ketika kegagalan itu terjadi di tengah transaksi.

Saya mulai melacak komentar PR saya karena saya merasa frustrasi. Saya akan meninjau kode, menyetujuinya, dan kemudian melihat pengembang yang sama membuat kesalahan yang sama di PR berikutnya. Umpan baliknya tidak tertanam. Jadi saya membuat spreadsheet. Setiap komentar yang saya tinggalkan dikategorikan: penanganan kesalahan, penamaan, pengujian, keamanan, kinerja, arsitektur, atau lainnya. Setelah enam bulan, saya memiliki cukup data untuk melihat pola. Setelah delapan belas bulan, pola-pola itu telah mengeraskan menjadi daftar periksa yang sebenarnya berfungsi.

Bagian yang mengejutkan bukan hanya apa yang menduduki daftar teratas—tetapi juga apa yang tidak. Komentar optimasi kinerja hanya membentuk 8% dari tinjauan saya. Masalah keamanan adalah 6%. Ini adalah hal-hal yang kita obses dengan dalam diskusi arsitektur, tetapi dalam PR sehari-hari, hal ini jarang terjadi. Apa yang umum? Pengembang yang berasumsi pada jalur bahagia, memberi nama dengan buruk, dan menulis pesan kesalahan untuk diri mereka sendiri alih-alih untuk orang yang akan melakukan debug pada tengah malam.

Pola Penanganan Kesalahan yang Terus Menghancurkan Produksi

Berikut daftar masalah penanganan kesalahan saya, diurutkan berdasarkan seberapa sering mereka menyebabkan insiden nyata:

1. Kegagalan diam dalam pekerjaan latar belakang. Kode menangkap pengecualian, mencatatnya, dan melanjutkan. Terasa masuk akal sampai Anda menyadari bahwa pekerjaan itu seharusnya mengirim email konfirmasi pembayaran. Sekarang pelanggan Anda berpikir mereka tidak dikenakan biaya, tetapi sebenarnya dikenakan biaya. Saya melihat pola ini pada 40% PR pekerjaan latar belakang. Perbaikannya sederhana: jika operasi itu kritis, jangan tangkap pengecualiannya—biarkan itu menggelembung dan memicu peringatan Anda. Jika tidak kritis, dokumentasikan mengapa baik untuk gagal secara diam-diam.
2. Pesan kesalahan generik yang menyembunyikan konteks. "Terjadi kesalahan" tidak memberi tahu saya apa-apa. "Gagal untuk memproses pembayaran" lebih baik tetapi masih tidak berguna. "Gagal mengenakan biaya kartu yang diakhiri 4242: dana tidak mencukupi (kode kesalahan: card_declined)" benar-benar membantu. Saya menandai ini di sekitar 30% PR. Uji yang saya gunakan: jika Anda melihat kesalahan ini di log produksi pada jam 3 pagi, bisakah Anda mendiagnosisnya tanpa menambahkan lebih banyak log dan melakukan redeploy?
3. Menangkap Exception daripada pengecualian spesifik. Ini kontroversial karena beberapa panduan gaya menyarankan hal itu, tetapi saya telah melihatnya menyembunyikan bug terlalu banyak kali. Ketika Anda menangkap Exception, Anda juga menangkap NullPointerException, IllegalStateException, dan semua pengecualian lain yang menunjukkan kesalahan programmer daripada kondisi runtime. Tangkap apa yang Anda harapkan untuk ditangani. Biarkan kesalahan programmer menyebabkan kegagalan—itulah cara Anda menemukannya.
4. Tidak memvalidasi data eksternal di batas. Respon API, input pengguna, konten file—jika itu berasal dari luar proses Anda, validasi segera. Saya melihat pengembang melakukan validasi di lapisan logika bisnis, yang berarti data tidak valid telah menyebar melalui beberapa fungsi. Pada saat itu, Anda sedang melakukan debug mengapa nilai null masuk ke basis data Anda. Validasi di batas, gagal cepat, kembali dengan kesalahan yang jelas.
5. Logika coba ulang tanpa penundaan eksponensial. Layanannya turun, jadi Anda mencoba ulang segera. Masih turun, jadi Anda mencoba ulang segera lagi. Selamat, Anda baru saja mengubah penurunan layanan menjadi pemadaman total dengan terus-menerus menyerang dengan coba ulang. Saya melihat ini di 15% PR yang menambahkan logika coba ulang. Selalu gunakan penundaan eksponensial dengan jitter. Selalu memiliki jumlah coba ulang maksimum. Selalu pertimbangkan apakah mencoba ulang bahkan masuk akal untuk operasi ini.
6. Tidak menangani kegagalan parsial dalam operasi batch. Anda sedang memproses 1.000 catatan. Catatan 500 gagal. Apa yang terjadi pada catatan 501-1000? Di sebagian besar kode yang saya tinjau, mereka tidak pernah diproses. Batch gagal, dicoba ulang, gagal lagi pada catatan 500, dan Anda terjebak. Tangani kegagalan parsial secara eksplisit: lacak apa yang berhasil, apa yang gagal, dan mengapa. Buat operasi batch Anda dapat dilanjutkan.
7. Mengasumsikan transaksi database akan selalu sukses. Anda memulai transaksi, melakukan beberapa pekerjaan, dan mengkomit. Tetapi bagaimana jika komit gagal? Bagaimana jika Anda kehilangan koneksi database di tengah transaksi? Saya melihat kode yang tidak menangani ini dalam 25% PR yang menyentuh kode database. Hasilnya: status aplikasi dan status basis data menyimpang, dan Anda menghabiskan berjam-jam untuk melakukan debug mengapa data tidak cocok dengan apa yang dikatakan log terjadi.

Hari Ketika Nama Variabel Menyebabkan Insiden $50.000

Itu adalah pagi Selasa ketika saya mendapat pesan Slack: "Kami baru saja mengembalikan $50.000 kepada pelanggan yang salah." Saya membuka saluran insiden dan mulai membaca. Seorang pengembang telah mendorong perbaikan semalam untuk bug dalam sistem pemrosesan pengembalian dana kami. Perbaikan itu hanya satu baris. PR telah disetujui oleh dua insinyur senior. Tes berhasil. Semuanya tampak baik-baik saja.

Bug itu ada di nama variabel. Kode aslinya memiliki variabel bernama `refundAmount` yang mewakili jumlah yang akan dikembalikan dalam sen. Pengembang menambahkan variabel baru bernama `refundAmount` yang mewakili jumlah dalam dolar. Mereka lupa untuk mengganti nama variabel asli. Kode itu berhasil dikompilasi—keduanya adalah bilangan bulat. Tes berhasil karena data uji kebetulan menggunakan jumlah di mana sen dan dolar cukup dekat sehingga pernyataan tidak menangkapnya.

Di produksi, kami memproses 200 pengembalian dana pagi itu. Setengah dari mereka adalah untuk jumlah yang salah. Pengembalian dana $10,00 menjadi pengembalian dana $1.000. Pengembalian dana $5,00 menjadi pengembalian dana $500. Pada saat seseorang menyadari, kami telah membayar lebih $50.000. Kami harus meninjau setiap pengembalian dana secara manual, menghubungi pelanggan, dan dalam beberapa kasus, meminta uang kembali. Butuh waktu tiga hari untuk membersihkannya.

Penyebab utama bukan kesalahan pengembang—semua orang membuat kesalahan. Itu karena kami memiliki dua variabel dengan nama yang sama mewakili unit yang berbeda dalam lingkup yang sama. Tinjauan kode tidak menangkapnya karena para penilai berfokus pada logika, bukan penamaan. Setelah insiden itu, saya menambahkan aturan ke daftar periksa saya: jika sebuah variabel mewakili kuantitas dengan unit, unitnya harus ada di dalam nama. Bukan `amount`, tetapi `amountCents` atau `amountDollars`. Bukan `duration`, tetapi `durationSeconds` atau `durationMilliseconds`.

Ini terlihat sepele u