ஒரு நாளைத் தீர்மானிப்பது எது?
புதிய அம்சங்களை உருவாக்கும்போது புரோகிராமர்கள் பெரும்பாலும் தவறான விஷயங்களில் கவனம் செலுத்துகிறார்கள்.
நீங்கள் பேக்எண்ட் தரவு (backend data), குறியீடு நகல் (code duplication) அல்லது செயல்திறன் (performance) ஆகியவற்றைப் பற்றி நினைக்கலாம். இந்தக் கேள்விகள் முக்கியம் தான். ஆனால் அவை மிக முக்கியமான கேள்விகள் அல்ல.
நான் அடிக்கடி இந்தத் தவறைச் செய்கிறேன். புத்திசாலித்தனமான வடிவங்கள் (patterns) மற்றும் சுத்தமான குறியீடு (clean code) ஆகியவற்றைக் கண்டு நான் உற்சாகமடைகிறேன். பயனர் அந்த அம்சத்தை எவ்வாறு பயன்படுத்துகிறார் என்பதை முழுமையாகப் புரிந்துகொள்வதற்கு முன்பே நான் குறியீட்டை எழுதத் தொடங்கிவிடுகிறேன். பிறகு, எனது குறியீடு வணிக இலக்குடன் (business goal) ஒத்துப்போகவில்லை என்பதை உணர்கிறேன்.
ஒரு காலண்டர் செயலியை உதாரணமாக எடுத்துக் கொள்வோம்.
ஒரு பயனர் விடுமுறையைக் குறிக்க மார்ச் 1-ஐக் கிளிக் செய்கிறார். ஆனால் செயலி அதற்குப் பதிலாக பிப்ரவரி 28-ஐக் குறிக்கிறது. இது கால மண்டலங்களால் (timezones) ஏற்படுகிறது.
டெவலப்பர் ஒரு Date பொருளைப் (object) பயன்படுத்தியுள்ளார். ஒரு Date பொருள் என்பது காலத்தின் ஒரு குறிப்பிட்ட தருணத்தைக் குறிக்கிறது.
டோக்கியோவில், நள்ளிரவில் மார்ச் 1 ஆக இருக்கும்போது, லண்டனில் இன்னும் பிப்ரவரி 28 ஆகத்தான் இருக்கும். உங்கள் குறியீடு தேதியைச் சேமிக்க UTC முறைகளைப் பயன்படுத்தினால், நாள் மாறிவிடும்.
தொழில்நுட்பச் செயலாக்கம் (technical implementation) வணிகத் தர்க்கத்திற்கு (business logic) முரணாக இருப்பதால் இந்தப் பிழை (bug) ஏற்படுகிறது.
ஒரு பயனர் நாட்களைப் பற்றித்தான் நினைக்கிறார். பயனர் UTC ஆஃப்செட்டுகள் (offsets) அல்லது மில்லிசெகண்ட் டைம்ஸ்டாம்புகளைப் (millisecond timestamps) பற்றிப் போவதில்லை. அவர்கள் "எனக்கு மார்ச் 14 வேண்டும்" என்றுதான் நினைக்கிறார்கள்.
உங்கள் குறியீடு நம்பகமானதாக இருக்க வேண்டுமென்றால், நீங்கள் டொமைனை (domain) சரியாக மாதிரியாக்க (model) வேண்டும்.
ஒரு காகித காலண்டரில், ஒரு தேதி என்பது ஒரு ஆண்டு, ஒரு மாதம் மற்றும் ஒரு நாள் மட்டுமே. அதில் கால மண்டலம் என்று எதுவும் இல்லை.
UTC அல்லது உள்ளூர் நேரத்துடன் (local time) ஒத்துப்போவதன் மூலம் நீங்கள் இந்தப் பிழையைச் சரிசெய்யலாம். ஆனால் அது ஒரு தற்காலிகத் தீர்வு (band-aid) மட்டுமே. தவறு செய்ய முடியாத தரவு கட்டமைப்புகளைப் (data structures) பயன்படுத்துவதே சிறந்த வழி.
ஒரு Date பொருளுக்குப் பதிலாக, ஒரு தனிப்பயன் பொருளைப் (custom object) பயன்படுத்துங்கள்:
• ஆண்டு: 2026 • மாதம்: மார்ச் • நாள்: 1
இது கணக்கீட்டிலிருந்து நேரம் மற்றும் கால மண்டலங்களை நீக்கிவிடுகிறது. இது பிழை ஏற்படுவதைத் தவிர்க்கிறது.
ஆம், இதற்கு அதிக வேலை தேவைப்படும். தேதிகளை ஒப்பிட அல்லது ஒரு மாதத்தின் இறுதி நாட்களைக் கண்டறிய நீங்கள் யூட்டிலிட்டிஸை (utilities) எழுத வேண்டியிருக்கும். உங்களுக்கு காலக்கெடு மற்றும் ஸ்பிரிண்ட்கள் (sprints) பற்றிய கவலைகள் இருக்கும்.
ஆனால் டொமைனைச் சரியாக மாதிரியாக்குவது, பின்னாளில் கோபமான சப்போர்ட் டிக்கெட்டுகளிலிருந்தும் (support tickets) பல மணிநேர டீபக்கிங்கிலிருந்தும் (debugging) உங்களைக் காப்பாற்றும்.
எரிக் எவன்ஸ் (Eric Evans) Domain-Driven Design-இல் கூறுவது போல:
"திறம்படத் தொடர்புகொள்ள, தேவைகளை எழுதப் பயன்படுத்தப்பட்ட அதே மொழியின் அடிப்படையில் குறியீடு இருக்க வேண்டும்."
ஒரு புரோகிராமராக மட்டும் சிந்திப்பதை நிறுத்துங்கள். வணிக விதிகைப் (business rules) பற்றிச் சிந்திக்கத் தொடங்குங்கள்.