ఒక రోజును ఏది నిర్వచిస్తుంది?
కొత్త ఫీచర్లను రూపొందించేటప్పుడు ప్రోగ్రామర్లు తరచుగా తప్పు విషయాలపై దృష్టి పెడతారు.
మీరు బ్యాకెండ్ డేటా, కోడ్ డూప్లికేషన్ లేదా పెర్ఫార్మెన్స్ గురించి ఆలోచించవచ్చు. ఈ ప్రశ్నలు ముఖ్యమే. కానీ ఇవి అత్యంత ముఖ్యమైన ప్రశ్నలు కావు.
నేను తరచుగా ఈ తప్పు చేస్తాను. స్మార్ట్ ప్యాటర్న్స్ మరియు క్లీన్ కోడ్ గురించి నేను ఉత్సాహపడతాను. వినియోగదారుడు ఆ ఫీచర్ను ఎలా ఉపయోగిస్తారో పూర్తిగా అర్థం చేసుకునే ముందే నేను కోడింగ్ ప్రారంభించగలను. అప్పుడు నా కోడ్ బిజినెస్ గోల్కు సరిపోలేదని నేను గ్రహిస్తాను.
ఉదాహరణకు ఒక క్యాలెండర్ యాప్ను తీసుకోండి.
ఒక వినియోగదారుడు సెలవును గుర్తించడానికి మార్చి 1వ తేదీని క్లిక్ చేస్తారు. కానీ యాప్ దానికి బదులుగా ఫిబ్రవరి 28వ తేదీని గుర్తిస్తుంది. ఇది టైమ్జోన్ల (timezones) వల్ల జరుగుతుంది.
డెవలపర్ ఒక Date ఆబ్జెక్ట్ను ఉపయోగించారు. Date ఆబ్జెక్ట్ అనేది సమయంలోని ఒక నిర్దిష్ట క్షణాన్ని సూచిస్తుంది.
టోక్యోలో అర్ధరాత్రి మార్చి 1వ తేదీ అయినప్పుడు, లండన్లో ఇంకా ఫిబ్రవరి 28వ తేదీనే ఉంటుంది. మీరు తేదీని సేవ్ చేయడానికి మీ కోడ్లో UTC మెథడ్స్ను ఉపయోగిస్తే, రోజు మారిపోతుంది.
టెక్నికల్ ఇంప్లిమెంటేషన్ బిజినెస్ లాజిక్కు విరుద్ధంగా ఉండటం వల్ల ఈ బగ్ ఏర్పడుతుంది.
వినియోగదారుడు రోజుల్లో ఆలోచిస్తారు. వినియోగదారుడు UTC ఆఫ్సెట్లు లేదా మిల్లీసెకండ్ టైమ్స్టాంప్ల గురించి ఆలోచించరు. వారు "నాకు మార్చి 14వ తేదీ కావాలి" అని మాత్రమే ఆలోచిస్తారు.
మీ కోడ్ నమ్మదగినదిగా ఉండాలంటే, మీరు డొమైన్ను (domain) సరిగ్గా మోడల్ చేయాలి.
పేపర్ క్యాలెండర్లో, ఒక తేదీ అంటే కేవలం సంవత్సరం, నెల మరియు రోజు మాత్రమే. దానికి టైమ్జోన్ ఉండదు.
UTC లేదా లోకల్ టైమ్తో స్థిరంగా ఉండటం ద్వారా మీరు ఈ బగ్ను సరిచేయవచ్చు. కానీ అది తాత్కాలిక పరిష్కారం (band-aid) మాత్రమే. విఫలం కాని డేటా స్ట్రక్చర్లను ఉపయోగించడం మెరుగైన మార్గం.
Date ఆబ్జెక్ట్కు బదులుగా, ఒక కస్టమ్ ఆబ్జెక్ట్ను ఉపయోగించండి:
• సంవత్సరం: 2026 • నెల: మార్చి • రోజు: 1
ఇది సమయం మరియు టైమ్జోన్లను లెక్కల నుండి తొలగిస్తుంది. దీనివల్ల బగ్ వచ్చే అవకాశం ఉండదు.
అవును, దీనికి ఎక్కువ పని అవసరం. తేదీలను పోల్చడానికి లేదా నెల చివరి రోజును కనుగొనడానికి మీరు యుటిలిటీలను (utilities) వ్రాయాల్సి ఉంటుంది. మీకు డెడ్లైన్లు మరియు స్పింట్లు (sprints) కూడా ఉంటాయి.
కానీ డొమైన్ను సరిగ్గా మోడల్ చేయడం వల్ల భవిష్యత్తులో కోపంతో కూడిన సపోర్ట్ టికెట్లు మరియు గంటల కొద్దీ డీబగ్గింగ్ నుండి మీరు తప్పించుకోవచ్చు.
ఎరిక్ ఎవాన్స్ 'Domain-Driven Design'లో చెప్పినట్లుగా:
"సమర్థవంతంగా కమ్యూనికేట్ చేయడానికి, అవసరాలను (requirements) వ్రాయడానికి ఉపయోగించిన భాషనే కోడ్ కూడా అనుసరించాలి."
కేవలం ఒక ప్రోగ్రామర్గా మాత్రమే ఆలోచించడం ఆపండి. బిజినెస్ రూల్స్ గురించి ఆలోచించడం ప్రారంభించండి.