What Defines a Day?
नवीन फीचर्स तयार करताना प्रोग्रामर्स अनेकदा चुकीच्या गोष्टींवर लक्ष केंद्रित करतात.
तुम्ही बॅकएंड डेटा, कोड डुप्लिकेशन किंवा परफॉर्मन्सचा विचार करत असाल. हे प्रश्न महत्त्वाचे आहेत. पण ते सर्वात महत्त्वाचे प्रश्न नाहीत.
मी अनेकदा ही चूक करतो. मी स्मार्ट पॅटर्न आणि क्लीन कोडबद्दल उत्साही होतो. युजर त्या फीचरचा वापर कसा करतो हे पूर्णपणे समजून घेण्यापूर्वीच मी कोडिंग सुरू करतो. मग मला जाणीव होते की माझा कोड बिझनेस गोलशी (business goal) जुळत नाहीये.
कॅलेंडर ॲपचे उदाहरण घेऊया.
एक युजर सुट्टी नोंदवण्यासाठी १ मार्चवर क्लिक करतो. पण ॲप त्याऐवजी २८ फेब्रुवारी नोंदवते. हे टाइमझोनमुळे (timezones) घडते.
डेव्हलपरने Date ऑब्जेक्ट वापरला होता. Date ऑब्जेक्ट वेळेतील एका विशिष्ट क्षणाचे प्रतिनिधित्व करतो.
टोकियोमध्ये, मध्यरात्री १ मार्च असेल, तर लंडनमध्ये अजूनही २८ फेब्रुवारी असेल. जर तुमचा कोड तारीख सेव्ह करण्यासाठी UTC मेथड्स वापरत असेल, तर दिवस बदलतो.
हा बग (bug) अस्तित्वात आहे कारण तांत्रिक अंमलबजावणी (technical implementation) बिझनेस लॉजिकच्या विरुद्ध आहे.
युजर दिवसांचा विचार करतो. युजर UTC ऑफसेट किंवा मिलिसेकंद टाइमस्टॅम्पचा विचार करत नाही. तो विचार करतो: "मला १४ मार्च हवा आहे."
जर तुम्हाला तुमचा कोड विश्वसनीय हवा असेल, तर तुम्हाला डोमेनचे (domain) योग्य मॉडेलिंग करणे आवश्यक आहे.
कागदी कॅलेंडरमध्ये, तारीख म्हणजे फक्त वर्ष, महिना आणि दिवस असतो. त्याला कोणताही टाइमझोन नसतो.
तुम्ही UTC किंवा लोकल टाइमशी सुसंगत राहून हा बग फिक्स करू शकता. पण तो फक्त तात्पुरता उपाय आहे. अधिक चांगला मार्ग म्हणजे असे डेटा स्ट्रक्चर्स वापरणे ज्यामध्ये चूक होण्याची शक्यता नसेल.
Date ऑब्जेक्टऐवजी, एक कस्टम ऑब्जेक्ट वापरा:
• वर्ष: 2026 • महिना: March • दिवस: 1
यामुळे वेळेचा आणि टाइमझोनचा प्रश्नच उरत नाही. यामुळे तो बग येणे अशक्य होते.
हो, यासाठी जास्त काम करावे लागते. तारखांची तुलना करण्यासाठी किंवा महिन्याचा शेवट शोधण्यासाठी तुम्हाला युटिलिटीज (utilities) लिहाव्या लागतील. तुम्हाला डेडलाईन्स आणि स्प्रिंट्सची (sprints) काळजी घ्यावी लागते.
पण डोमेनचे योग्य मॉडेलिंग केल्यामुळे तुम्ही नंतरच्या रागीट सपोर्ट तिकिटांपासून आणि तासनतास चालणाऱ्या डीबगिंगपासून (debugging) वाचता.
एरिक इव्हान्स 'Domain-Driven Design' मध्ये म्हणतात:
"प्रभावीपणे संवाद साधण्यासाठी, कोड हा आवश्यकता (requirements) लिहिण्यासाठी वापरल्या जाणाऱ्या भाषेशी सुसंगत असावा."
केवळ प्रोग्रामर म्हणून विचार करणे थांबवा. बिझनेस रूल्सचा (business rules) विचार करायला सुरुवात करा.