ഒരു ദിവസത്തെ നിർവചിക്കുന്നത് എന്താണ്?
പുതിയ ഫീച്ചറുകൾ നിർമ്മിക്കുമ്പോൾ പ്രോഗ്രാമർമാർ പലപ്പോഴും തെറ്റായ കാര്യങ്ങളിലാണ് ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത്.
ബാക്കെൻഡ് ഡാറ്റ, കോഡ് ഡ്യൂപ്ലിക്കേഷൻ അല്ലെങ്കിൽ പെർഫോമൻസ് എന്നിവയെക്കുറിച്ചായിരിക്കാം നിങ്ങൾ ചിന്തിക്കുന്നത്. ഈ ചോദ്യങ്ങൾ പ്രധാനമാണ്. എന്നാൽ അവയല്ല ഏറ്റവും പ്രധാനപ്പെട്ട ചോദ്യങ്ങൾ.
ഞാൻ പലപ്പോഴും ഈ തെറ്റ് ചെയ്യാറുണ്ട്. സ്മാർട്ട് പാറ്റേണുകളെക്കുറിച്ചും ക്ലീൻ കോഡിനെക്കുറിച്ചും ആവേശഭരിതനാകാൻ എനിക്ക് എളുപ്പമാണ്. ഉപയോക്താവ് ആ ഫീച്ചർ എങ്ങനെയാണ് ഉപയോഗിക്കുന്നത് എന്ന് പൂർണ്ണമായി മനസ്സിലാക്കുന്നതിന് മുമ്പ് തന്നെ ഞാൻ കോഡിംഗ് തുടങ്ങുന്നു. പിന്നീട് എന്റെ കോഡ് ബിസിനസ്സ് ലക്ഷ്യങ്ങളുമായി പൊരുത്തപ്പെടുന്നില്ലെന്ന് ഞാൻ തിരിച്ചറിയുന്നു.
ഒരു കലണ്ടർ ആപ്പ് ഉദാഹരണമായി എടുക്കാം.
ഒരു ഉപയോക്താവ് ഒരു അവധി ദിനം അടയാളപ്പെടുത്താൻ മാർച്ച് 1-ൽ ക്ലിക്ക് ചെയ്യുന്നു. എന്നാൽ ആപ്പ് പകരം ഫെബ്രുവരി 28 ആണ് അടയാളപ്പെടുത്തുന്നത്. ടൈംസോണുകൾ (timezones) കാരണമാണ് ഇത് സംഭവിക്കുന്നത്.
ഡെവലപ്പർ ഒരു Date ഒബ്ജക്റ്റ് ആണ് ഉപയോഗിച്ചത്. ഒരു Date ഒബ്ജക്റ്റ് എന്നത് സമയത്തിലെ ഒരു പ്രത്യേക നിമിഷത്തെയാണ് സൂചിപ്പിക്കുന്നത്.
ടോക്കിയോയിൽ അർദ്ധരാത്രിയിലെ മാർച്ച് 1 എന്നത് ലണ്ടനിൽ ഇപ്പോഴും ഫെബ്രുവരി 28 ആണ്. ഡേറ്റ് സേവ് ചെയ്യാൻ നിങ്ങളുടെ കോഡ് UTC മെത്തേഡുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, ദിവസം മാറിക്കൊണ്ടിരിക്കും.
സാങ്കേതികമായ നടപ്പിലാക്കൽ (technical implementation) ബിസിനസ്സ് ലോജിക്കുമായി പൊരുത്തപ്പെടാത്തതുകൊണ്ടാണ് ഈ ബഗ് (bug) ഉണ്ടാകുന്നത്.
ഒരു ഉപയോക്താവ് ദിവസങ്ങളെ അടിസ്ഥാനമാക്കിയാണ് ചിന്തിക്കുന്നത്. ഉപയോക്താവ് UTC ഓഫ്സെറ്റുകളെക്കുറിച്ചോ മില്ലിസെക്കൻഡ് ടൈംസ്റ്റാമ്പുകളെക്കുറിച്ചോ ചിന്തിക്കുന്നില്ല. അവർ ചിന്തിക്കുന്നത്: "എനിക്ക് മാർച്ച് 14 വേണം" എന്നാണ്.
നിങ്ങളുടെ കോഡ് വിശ്വസനീയമാകണമെന്നുണ്ടെങ്കിൽ, നിങ്ങൾ ഡൊമൈനിനെ (domain) ശരിയായി മോഡൽ ചെയ്യണം.
ഒരു പേപ്പർ കലണ്ടറിൽ, ഒരു തീയതി എന്നത് വെറുമൊരു വർഷം, ഒരു മാസം, ഒരു ദിവസം എന്നിവ മാത്രമാണ്. അതിന് ടൈംസോൺ ഇല്ല.
UTC അല്ലെങ്കിൽ ലോക്കൽ ടൈമുമായി പൊരുത്തപ്പെടുന്നത് വഴി നിങ്ങൾക്ക് ഈ ബഗ് പരിഹരിക്കാം. എന്നാൽ അത് ഒരു താൽക്കാലിക പരിഹാരം (band-aid) മാത്രമാണ്. പരാജയപ്പെടാൻ സാധ്യതയില്ലാത്ത ഡാറ്റാ സ്ട്രക്ചറുകൾ ഉപയോഗിക്കുന്നതാണ് ഇതിന് നല്ലൊരു വഴി.
ഒരു Date ഒബ്ജക്റ്റിന് പകരം, ഒരു കസ്റ്റം ഒബ്ജക്റ്റ് ഉപയോഗിക്കുക:
• വർഷം: 2026 • മാസം: മാർച്ച് • ദിവസം: 1
ഇത് സമയത്തെയും ടൈംസോണുകളെയും കണക്കിൽ നിന്ന് ഒഴിവാക്കുന്നു. ഇത് ബഗ് ഉണ്ടാകുന്നത് അസാധ്യമാക്കുന്നു.
അതെ, ഇതിന് കൂടുതൽ ജോലി ആവശ്യമാണ്. തീയതികൾ താരതമ്യം ചെയ്യാനോ ഒരു മാസത്തിന്റെ അവസാനം കണ്ടെത്താനോ ഉള്ള യൂട്ടിലിറ്റികൾ (utilities) നിങ്ങൾ എഴുതേണ്ടി വരും. നിങ്ങൾക്ക് ഡെഡ്ലൈനുകളും സ്പ്രിന്റുകളും (sprints) ഉണ്ടല്ലോ.
എന്നാൽ ഡൊമൈനിനെ ശരിയായി മോഡൽ ചെയ്യുന്നത് പിന്നീട് ദേഷ്യപ്പെട്ടുകൊണ്ടുള്ള സപ്പോർട്ട് ടിക്കറ്റുകളിൽ നിന്നും മണിക്കൂറുകൾ നീണ്ട ഡീബഗ്ഗിംഗിൽ നിന്നും നിങ്ങളെ രക്ഷിക്കും.
എറിക് ഇവാൻസ് (Eric Evans) 'Domain-Driven Design'-ൽ പറയുന്നത് പോലെ:
"ഫലപ്രദമായി ആശയവിനിമയം നടത്താൻ, ആവശ്യകതകൾ (requirements) എഴുതാൻ ഉപയോഗിച്ച അതേ ഭാഷയിൽ തന്നെ കോഡും അധിഷ്ഠിതമായിരിക്കണം."
ഒരു പ്രോഗ്രാമർ എന്ന നിലയിൽ മാത്രം ചിന്തിക്കുന്നത് നിർത്തുക. ബിസിനസ്സ് നിയമങ്ങളെക്കുറിച്ച് ചിന്തിച്ചു തുടങ്ങുക.