ایک دن کا تعین کیا کرتا ہے؟
پروگرامرز اکثر نئے فیچرز بناتے وقت غلط چیزوں پر توجہ مرکوز کرتے ہیں۔
آپ بیک اینڈ ڈیٹا، کوڈ کی تکرار (code duplication)، یا کارکردگی (performance) کے بارے میں سوچ سکتے ہیں۔ یہ سوالات اہم ہیں، لیکن یہ سب سے اہم سوالات نہیں ہیں۔
میں اکثر یہ غلطی کرتا ہوں۔ میں اسمارٹ پیٹرنز اور کلین کوڈ کے بارے میں پرجوش ہو جاتا ہوں۔ میں اس سے پہلے کوڈنگ شروع کر دیتا ہوں کہ میں مکمل طور پر سمجھ سکوں کہ صارف فیچر کو کیسے استعمال کرتا ہے۔ پھر مجھے احساس ہوتا ہے کہ میرا کوڈ کاروباری مقصد (business goal) کے مطابق نہیں ہے۔
مثال کے طور پر ایک کیلنڈر ایپ لیں۔
ایک صارف چھٹی کے طور پر یکم مارچ پر کلک کرتا ہے۔ لیکن ایپ اس کے بجائے 28 فروری کو نشان زد کر دیتی ہے۔ ایسا ٹائم زونز (timezones) کی وجہ سے ہوتا ہے۔
ڈیولپر نے ایک Date object استعمال کیا۔ ایک Date object وقت کے ایک مخصوص لمحے کی نمائندگی کرتا ہے۔
ٹوکیو میں، آدھی رات کو یکم مارچ کا وقت لندن میں ابھی بھی 28 فروری ہوتا ہے۔ اگر آپ کا کوڈ تاریخ محفوظ کرنے کے لیے UTC طریقوں کا استعمال کرتا ہے، تو دن بدل جاتا ہے۔
یہ بگ (bug) اس لیے موجود ہے کیونکہ تکنیکی عمل (technical implementation) کاروباری منطق (business logic) کے منافی ہے۔
ایک صارف دنوں کے حساب سے سوچتا ہے۔ صارف UTC آفسیٹس یا ملی سیکنڈ ٹائم اسٹیمپ کے بارے میں نہیں سوچتا۔ وہ سوچتا ہے: "مجھے 14 مارچ چاہیے"۔
اگر آپ چاہتے ہیں کہ آپ کا کوڈ قابل اعتماد ہو، تو آپ کو ڈومین (domain) کی درست طریقے سے ماڈلنگ کرنی چاہیے۔
کاغذ کے کیلنڈر میں، ایک تاریخ محض ایک سال، ایک مہینہ اور ایک دن ہوتی ہے۔ اس کا کوئی ٹائم زون نہیں ہوتا۔
آپ UTC یا مقامی وقت کے ساتھ ہم آہنگ ہو کر بگ کو ٹھیک کر سکتے ہیں۔ لیکن یہ صرف ایک عارضی حل (band-aid) ہے۔ ایک بہتر طریقہ ایسے ڈیٹا اسٹرکچرز کا استعمال کرنا ہے جو ناکام نہ ہو سکیں۔
Date object کے بجائے، ایک کسٹم آبجیکٹ استعمال کریں:
• سال: 2026 • مہینہ: March • دن: 1
یہ مساوات سے وقت اور ٹائم زونز کو ختم کر دیتا ہے۔ یہ بگ کو ناممکن بنا دیتا ہے۔
جی ہاں، اس میں زیادہ کام لگتا ہے۔ آپ کو تاریخوں کا موازنہ کرنے یا مہینے کا اختتام تلاش کرنے کے لیے یوٹیلیٹیز (utilities) لکھنی پڑتی ہیں۔ آپ کو ڈیڈ لائنز اور اسپرنٹس (sprints) کی بھی فکر کرنی ہوتی ہے۔
لیکن ڈومین کی درست ماڈلنگ آپ کو بعد میں غصے بھرے سپورٹ ٹکٹس اور گھنٹوں کی ڈی بگنگ (debugging) سے بچاتی ہے۔
جیسا کہ ایرک ایونز Domain-Driven Design میں کہتے ہیں:
"موثر طریقے سے بات چیت کرنے کے لیے، کوڈ کو اسی زبان پر مبنی ہونا چاہیے جو ضروریات (requirements) لکھنے کے لیے استعمال کی گئی ہو۔"
صرف ایک پروگرامر کے طور پر سوچنا بند کریں۔ کاروباری اصولوں (business rules) کے بارے میں سوچنا شروع کریں۔