દિવસ શું નક્કી કરે છે?
નવી સુવિધાઓ બનાવતી વખતે પ્રોગ્રામરો ઘણીવાર ખોટી બાબતો પર ધ્યાન કેન્દ્રિત કરે છે.
તમે બેકએન્ડ ડેટા, કોડ ડુપ્લીકેશન અથવા પર્ફોર્મન્સ વિશે વિચારી શકો છો. આ પ્રશ્નો મહત્વના છે. પરંતુ તે સૌથી મહત્વપૂર્ણ પ્રશ્નો નથી.
હું ઘણીવાર આ ભૂલ કરું છું. હું સ્માર્ટ પેટર્ન અને ક્લીન કોડ વિશે ઉત્સાહિત થઈ જાઉં છું. યુઝર સુવિધાનો ઉપયોગ કેવી રીતે કરે છે તે સંપૂર્ણ રીતે સમજ્યા વિના હું કોડિંગ શરૂ કરી દઉં છું. પછી મને સમજાય છે કે મારો કોડ બિઝનેસ ગોલ સાથે મેળ ખાતો નથી.
ઉદાહરણ તરીકે કેલેન્ડર એપ લો.
એક યુઝર રજા તરીકે માર્ચ 1 તારીખ પર ક્લિક કરે છે. પરંતુ એપ તેના બદલે ફેબ્રુઆરી 28 તારીખ માર્ક કરે છે. આ ટાઈમઝોન (timezones) ને કારણે થાય છે.
ડેવલપરે Date object નો ઉપયોગ કર્યો હતો. Date object સમયના એક ચોક્કસ ક્ષણને દર્શાવે છે.
ટોક્યોમાં, મધ્યરાત્રિએ માર્ચ 1 તારીખ હોય છે, જ્યારે લંડનમાં હજુ પણ ફેબ્રુઆરી 28 તારીખ હોય છે. જો તમારો કોડ તારીખ સેવ કરવા માટે UTC મેથડ્સનો ઉપયોગ કરે છે, તો દિવસ બદલાઈ જાય છે.
આ બગ (bug) એટલા માટે છે કારણ કે ટેકનિકલ અમલીકરણ (technical implementation) બિઝનેસ લોજિક સાથે વિરોધાભાસ ધરાવે છે.
યુઝર દિવસોમાં વિચારે છે. યુઝર UTC ઓફસેટ્સ અથવા મિલિસેકન્ડ ટાઈમસ્ટેમ્પમાં વિચારતો નથી. તેઓ વિચારે છે: "મારે માર્ચ 14 જોઈએ છે."
જો તમે તમારા કોડને વિશ્વસનીય બનાવવા માંગતા હોવ, તો તમારે ડોમેનને (domain) યોગ્ય રીતે મોડેલ કરવું જોઈએ.
કાગળના કેલેન્ડરમાં, તારીખ એટલે ફક્ત વર્ષ, મહિનો અને દિવસ છે. તેમાં કોઈ ટાઈમઝોન હોતો નથી.
તમે UTC અથવા લોકલ ટાઈમ સાથે સુસંગત રહીને બગને ઠીક કરી શકો છો. પરંતુ તે માત્ર કામચલાઉ ઉપાય (band-aid) છે. વધુ સારો રસ્તો એ છે કે એવા ડેટા સ્ટ્રક્ચર્સનો ઉપયોગ કરવો જે નિષ્ફળ ન જાય.
Date object ને બદલે, કસ્ટમ ઓબ્જેક્ટનો ઉપયોગ કરો:
• વર્ષ: 2026 • મહિનો: માર્ચ • દિવસ: 1
આ સમીકરણમાંથી સમય અને ટાઈમઝોનને દૂર કરે છે. આનાથી બગ થવો અશક્ય બની જાય છે.
હા, આમાં વધુ કામ કરવું પડે છે. તમારે તારીખોની સરખામણી કરવા અથવા મહિનાનો અંત શોધવા માટે યુટિલિટીઝ (utilities) લખવી પડશે. તમારે ડેડલાઇન્સ અને સ્પ્રિન્ટ્સ (sprints) વિશે પણ ચિંતા કરવી પડશે.
પરંતુ ડોમેનને યોગ્ય રીતે મોડેલ કરવાથી તમે પછીથી ગુસ્સાવાળા સપોર્ટ ટિકિટ્સ અને કલાકોના ડીબગિંગ (debugging) થી બચી શકો છો.
જેમ એરિક ઇવાન્સ Domain-Driven Design માં કહે છે:
"અસરકારક રીતે વાતચીત કરવા માટે, કોડ એ જ ભાષા પર આધારિત હોવો જોઈએ જેનો ઉપયોગ જરૂરિયાતો લખવા માટે કરવામાં આવ્યો હોય."
માત્ર એક પ્રોગ્રામર તરીકે વિચારવાનું બંધ કરો. બિઝનેસ નિયમો વિશે વિચારવાનું શરૂ કરો.