Apakah yang Menentukan Sebuah Hari?
Pengatur cara sering kali memberi tumpuan kepada perkara yang salah apabila membina ciri baharu.
Anda mungkin berfikir tentang data backend, duplikasi kod, atau prestasi. Persoalan-persoalan ini penting. Tetapi ia bukanlah persoalan yang paling utama.
Saya sering melakukan kesilapan ini. Saya berasa teruja dengan corak pintar dan kod yang bersih. Saya mula menulis kod sebelum saya memahami sepenuhnya bagaimana pengguna menggunakan ciri tersebut. Kemudian saya menyedari kod saya tidak selaras dengan matlamat perniagaan.
Ambil aplikasi kalendar sebagai contoh.
Seorang pengguna mengklik pada 1 Mac untuk menandakan cuti umum. Tetapi aplikasi tersebut menandakan 28 Februari sebagai ganti. Ini berlaku disebabkan oleh zon masa.
Pembangun menggunakan objek Date. Objek Date mewakili satu detik masa yang spesifik.
Di Tokyo, 1 Mac pada tengah malam masih lagi 28 Februari di London. Jika kod anda menggunakan kaedah UTC untuk menyimpan tarikh, hari tersebut akan beralih.
Pepijat tersebut wujud kerana pelaksanaan teknikal bercanggah dengan logik perniagaan.
Seorang pengguna berfikir dalam bentuk hari. Pengguna tidak berfikir dalam bentuk offset UTC atau cap masa milisaat. Mereka berfikir: "Saya mahu 14 Mac."
Jika anda mahu kod anda boleh dipercayai, anda mesti memodelkan domain dengan betul.
Dalam kalendar kertas, tarikh hanyalah tahun, bulan, dan hari. Ia tidak mempunyai zon masa.
Anda boleh membaiki pepijat tersebut dengan menjadi konsisten dengan UTC atau masa tempatan. Tetapi itu hanyalah penyelesaian sementara. Cara yang lebih baik adalah dengan menggunakan struktur data yang tidak boleh gagal.
Daripada menggunakan objek Date, gunakan objek tersuai:
• Tahun: 2026 • Bulan: Mac • Hari: 1
Ini mengeluarkan faktor masa dan zon masa daripada persamaan tersebut. Ia menjadikan pepijat tersebut mustahil untuk berlaku.
Ya, ini memerlukan lebih banyak kerja. Anda perlu menulis utiliti untuk membandingkan tarikh atau mencari akhir bulan. Anda mempunyai tarikh akhir dan sprint yang perlu diuruskan.
Tetapi memodelkan domain dengan betul menyelamatkan anda daripada tiket sokongan yang marah dan berjam-jam proses penyahpepijatan kemudian hari.
Seperti yang dikatakan oleh Eric Evans dalam Domain-Driven Design:
"Untuk berkomunikasi secara berkesan, kod mestilah berasaskan bahasa yang sama yang digunakan untuk menulis keperluan."
Berhenti berfikir hanya sebagai seorang pengatur cara. Mula berfikir tentang peraturan perniagaan.