Apa yang Mendefinisikan Sebuah Hari?
Programmer sering kali berfokus pada hal yang salah saat membangun fitur baru.
Anda mungkin memikirkan tentang data backend, duplikasi kode, atau performa. Pertanyaan-pertanyaan ini penting. Namun, itu bukanlah pertanyaan yang paling utama.
Saya sering melakukan kesalahan ini. Saya merasa bersemangat dengan pola yang cerdas dan kode yang bersih. Saya mulai menulis kode sebelum saya sepenuhnya memahami bagaimana pengguna menggunakan fitur tersebut. Kemudian saya menyadari bahwa kode saya tidak sesuai dengan tujuan bisnis.
Ambil contoh aplikasi kalender.
Seorang pengguna mengklik 1 Maret untuk menandai hari libur. Namun, aplikasi justru menandai 28 Februari. Hal ini terjadi karena zona waktu.
Pengembang menggunakan objek Date. Sebuah objek Date merepresentasikan momen spesifik dalam waktu.
Di Tokyo, 1 Maret tengah malam masih merupakan 28 Februari di London. Jika kode Anda menggunakan metode UTC untuk menyimpan tanggal, harinya akan bergeser.
Bug tersebut ada karena implementasi teknis bertentangan dengan logika bisnis.
Seorang pengguna berpikir dalam satuan hari. Pengguna tidak berpikir dalam offset UTC atau timestamp milidetik. Mereka berpikir: "Saya ingin tanggal 14 Maret."
Jika Anda ingin kode Anda andal, Anda harus memodelkan domain dengan benar.
Dalam kalender kertas, sebuah tanggal hanyalah tahun, bulan, dan hari. Ia tidak memiliki zona waktu.
Anda dapat memperbaiki bug tersebut dengan bersikap konsisten menggunakan UTC atau waktu lokal. Namun, itu hanyalah solusi sementara. Cara yang lebih baik adalah menggunakan struktur data yang tidak mungkin gagal.
Alih-alih menggunakan objek Date, gunakan objek kustom:
• Tahun: 2026 • Bulan: Maret • Hari: 1
Ini menghilangkan faktor waktu dan zona waktu dari perhitungan. Hal ini membuat bug tersebut mustahil terjadi.
Ya, ini membutuhkan lebih banyak pekerjaan. Anda harus menulis utilitas untuk membandingkan tanggal atau mencari akhir bulan. Anda memiliki tenggat waktu dan sprint yang harus dikhawatirkan.
Namun, memodelkan domain dengan benar akan menyelamatkan Anda dari tiket dukungan yang marah dan berjam-jam proses debugging nantinya.
Seperti yang dikatakan Eric Evans dalam Domain-Driven Design:
"Untuk berkomunikasi secara efektif, kode harus didasarkan pada bahasa yang sama yang digunakan untuk menulis persyaratan."
Berhentilah berpikir hanya sebagai seorang programmer. Mulailah berpikir tentang aturan bisnis.