نیٹ ورک انجینئر کی حقیقت (نوڈلز اور... نمک کے ساتھ؟)
حال ہی میں، انجینئرز کے ساتھ مختلف واقعات پر گفتگو کرتے ہوئے، میں نے ایک دلچسپ نمونہ دیکھا۔
ان مباحثوں میں، "بنیادی وجہ" کا سوال ہمیشہ سامنے آتا ہے۔ ایماندار قارئین شاید جانتے ہیں کہ میرے پاس ہے۔
جب آپ اس خیال کو چیلنج کرتے ہیں اور اس بات کی نشاندہی کرتے ہیں کہ پیچیدہ نظاموں میں خطوطیت یقینی طور پر دھوکہ دیتی ہے، تو ایک دلچسپ بحث جنم لیتی ہے۔ تنازعہ کرنے والے جذباتی طور پر اصرار کرتے ہیں کہ صرف "بنیادی وجہ" کا علم ہی ہمیں یہ سمجھنے کی اجازت دیتا ہے کہ کیا ہو رہا ہے۔
میں نے ایک دلچسپ نمونہ دیکھا: ڈویلپرز اور ڈیوپس اس خیال پر مختلف ردعمل کا اظہار کرتے ہیں۔ میرے تجربے میں، ڈویلپرز یہ بحث کرنے کا زیادہ امکان رکھتے ہیں کہ بنیادی وجہ اہمیت رکھتی ہے اور یہ کہ وجہ اور اثر کے تعلقات ہمیشہ واقعات میں قائم ہو سکتے ہیں۔ دوسری طرف، DevOps اکثر اس بات پر متفق ہوتے ہیں کہ ایک پیچیدہ دنیا ہمیشہ خطوط کی پابندی نہیں کرتی ہے۔
میں ہمیشہ سوچتا تھا کہ ایسا کیوں ہے؟ کیا بناتا ہے پروگرامرز اس خیال پر تنقید کرتے ہیں کہ "بنیادی وجہ ایک افسانہ ہے"؟ ایک مدافعتی نظام کی طرح جو غیر ملکی ایجنٹ کو پہچانتا ہے۔ وہ اس طرح کیوں ردعمل کرتے ہیں، جبکہ ڈیوپس بلکہ مائل اس خیال پر غور کریں؟
مجھے پوری طرح یقین نہیں ہے، لیکن میرے پاس اس پر کچھ خیالات ہیں۔ اس کا تعلق مختلف سیاق و سباق سے ہے جس میں یہ پیشہ ور اپنے روزمرہ کا کام انجام دیتے ہیں۔
ڈویلپر اکثر تعییناتی ٹولز کے ساتھ کام کرتے ہیں۔ بلاشبہ، کمپائلرز، لنکرز، آپریٹنگ سسٹم سبھی پیچیدہ نظام ہیں، لیکن ہم اس حقیقت کے عادی ہیں کہ وہ ایک تعییناتی نتیجہ دیتے ہیں، اور ہم ان کو تعین کے طور پر تصور کرتے ہیں: اگر ہم ایک ہی ان پٹ ڈیٹا فراہم کرتے ہیں، تو ہم عام طور پر ایک ہی آؤٹ پٹ کی توقع کرتے ہیں۔ ان نظاموں سے اور اگر آؤٹ پٹ ("بگ") میں کوئی مسئلہ ہے، تو ڈویلپرز ان پٹ ڈیٹا (یا تو صارف کی طرف سے یا ترقیاتی عمل کے دوران ٹولز کے سیٹ سے) کا تجزیہ کرکے اسے حل کرتے ہیں۔ وہ ایک "خرابی" تلاش کرتے ہیں اور پھر ان پٹ ڈیٹا کو تبدیل کرتے ہیں۔ یہ "بگ" کو ٹھیک کرتا ہے۔
سافٹ ویئر ڈویلپمنٹ کا بنیادی مفروضہ: ایک ہی ان پٹ ڈیٹا قابل اعتماد اور متعین طور پر ایک ہی آؤٹ پٹ تیار کرتا ہے۔
درحقیقت، ایک غیر متعین نتیجہ بذات خود ایک بگ سمجھا جاتا ہے: اگر غیر متوقع یا غلط آؤٹ پٹ کو دوبارہ پیش نہیں کیا جاتا ہے، تو ڈویلپر تحقیقات کو اسٹیک کے دوسرے حصوں (آپریٹنگ سسٹم، نیٹ ورک، وغیرہ) تک بڑھاتے ہیں جو زیادہ برتاؤ کرتے ہیں۔ یا کم تعییناتی طور پر، ایک ہی ان پٹ ڈیٹا کے ساتھ ایک ہی نتیجہ پیدا کرنا... اور اگر یہ نہیں ہے، پھر یہ اب بھی ایک بگ سمجھا جاتا ہے۔ یہ ابھی ایک آپریٹنگ سسٹم یا نیٹ ورک بگ ہے۔
کسی بھی صورت میں، ڈیٹرمنزم ایک بنیادی، تقریباً قابل قبول مفروضہ ہے جو پروگرامرز کرتے ہیں۔
لیکن کسی بھی ڈیوپس آدمی کے لیے جس نے ہارڈ ویئر کو ریک کرنے یا کلاؤڈ API کا پتہ لگانے میں دن گزارا ہو، ایک مکمل طور پر متعین دنیا کا خیال (جب تک کہ تمام ان پٹس کو نقشہ بنانا ممکن ہو!) بہترین تصور ہے۔ چاہے آپ اسے ایک طرف رکھ دیں۔
اس لیے تجربہ کار انجینئرز کے لیے یہ شک کرنا آسان ہے کہ تمام واقعات کی ایک ہی بنیادی وجہ ہے، اور "فائیو وائز" جیسی تکنیک صحیح طریقے سے (اور بار بار!) اس بنیادی وجہ کی طرف لے جائے گی۔ درحقیقت، یہ ان کے اپنے تجربے سے متصادم ہے، جہاں پہیلی کے ٹکڑے عملی طور پر اتنی صفائی سے فٹ نہیں ہوتے۔ اس لیے وہ اس خیال کو زیادہ آسانی سے قبول کرتے ہیں۔
بلاشبہ، میں یہ نہیں کہہ رہا ہوں کہ ڈویلپرز بولی، بیوقوف، یا یہ سمجھنے سے قاصر ہیں کہ لکیرییت کس طرح دھوکہ دہی ہوسکتی ہے۔
لیکن مجھے ایسا لگتا ہے کہ ان مباحثوں میں ڈویلپرز کی طرف سے ایک عام ردعمل کا اکثر اس حقیقت کے ساتھ تعلق ہوتا ہے کہ عزم کا تصور مجموعی طور پر ان کی اچھی طرح خدمت کرتا ہے۔ روزمرہ کے کام میں. ان کا سامنا اتنی بار نہیں ہوتا کہ انجینئرز کو شروڈنگر کی بلیوں کو ان کے انفراسٹرکچر پر پکڑنا پڑتا ہے۔
یہ مشاہدہ شدہ ڈویلپر کے رد عمل کی پوری طرح وضاحت نہیں کرسکتا ہے، لیکن یہ ایک طاقتور یاد دہانی ہے کہ ہمارے رد عمل بہت سے عوامل کا ایک پیچیدہ مرکب ہیں۔
اس پیچیدگی کو یاد رکھنا ضروری ہے، چاہے ہم کسی ایک واقعے سے نمٹ رہے ہوں، سافٹ ویئر ڈیلیوری پائپ لائن پر تعاون کر رہے ہوں، یا وسیع تر دنیا کا احساس دلانے کی کوشش کر رہے ہوں۔
ماخذ: www.habr.com