جس منصوبے کو آپ چھوڑ دیتے ہیں، وہی وہ خرابی ہے جو آپ بعد میں ڈیبگ کریں گے
سافٹ ویئر انجینئرنگ میں ہر فریم ورک آپ کو تیزی سے چلنے، جلد شپ کرنے، پروڈکشن میں اٹریٹ کرنے کا کہتا ہے۔ AI سے تیار کی گئی ویب سائٹس کے لیے، یہ الٹا ہے۔ یہاں کا بلڈر آپ کے پرامپٹ سے سیدھا کوڈ سٹریم کرنے سے انکار کرتا ہے — یہ رک جاتا ہے، ایک منصوبہ لکھتا ہے، اور آپ کے دیکھنے کا انتظار کرتا ہے — اور یہی وہ واحد فیصلہ ہے جس کے گرد اس پائپ لائن کی باقی ہر چیز بنائی گئی ہے۔ شروع میں سست، بعد میں ہر جگہ سستا۔ میں یہ سودا ہر بار کروں گا، اور میرے خیال میں مخالف دلیل دینے والے زیادہ تر لوگوں نے یہ نہیں دیکھا کہ ایک غلط اندازہ بعد میں کیا نقصان دیتا ہے۔
یہاں ناکامی کا وہ طریقہ ہے جسے روکنے کے لیے منصوبہ موجود ہے۔ آپ "میرے اسٹوڈیو کے لیے بکنگ سائٹ" ٹائپ کرتے ہیں اور گو دباتے ہیں۔ سسٹم کو اندازہ لگانا ہوتا ہے کہ "بکنگ" کا کیا مطلب ہے — ایک کیلنڈر ویجٹ، تھرڈ پارٹی ایمبیڈ، یا تصادم چیک کے ساتھ حقیقی ریزرویشن سسٹم — اور یہ اسے کچھ لکھنے سے پہلے کرنا ہوتا ہے، کیونکہ کرنے کا کوئی اور ترتیب موجود نہیں۔ منصوبے کے اندر غلط اندازہ لگائیں تو تصحیح ایک جملہ، پانچ سیکنڈ، ختم۔ تیار شدہ کوڈ کے اندر غلط اندازہ لگائیں تو اب آپ کوئی جملہ ایڈٹ نہیں کر رہے، آپ دس فائلوں کو کھول رہے ہیں جو پہلے سے غلط مفروضے پر انحصار کرتی ہیں۔ میں نے دونوں صورتیں دیکھی ہیں۔ منصوبہ-مرحلے کی تصحیح ایک بات چیت ہوتی ہے۔ جنریشن کے بعد اسی ابہام پر پیوٹ کرنا ضائع کرکے دوبارہ بنانا ہوتا ہے۔
منصوبہ محض کاموں کی فہرست نہیں ہے، اور یہی وہ حصہ ہے جو لوگ نظرانداز کرتے ہیں۔ یہ ایک معاہدہ ہے، اور سسٹم خود کو اس کا پابند رکھتا ہے: ایک کنفارمنس-چیک ویریفائر، ان ایجنٹس میں سے ایک جسے بلڈ شپ ہونے سے پہلے منظوری دینا ضروری ہے، تیار سائٹ کا آپ کے منظور شدہ منصوبے سے موازنہ کرتا ہے۔ کیا تمام منصوبہ بند صفحات بنے؟ کیا فیچر لسٹ اسی سے میچ کرتی ہے جو شپ ہوا؟ یہاں "مکمل" کوئی احساس نہیں ہے — یہ ایک تحریری وعدے کے مقابلے میں ہے، سطر بہ سطر قابلِ جانچ۔ یہ "کوڈ چلتا ہے" سے زیادہ مضبوط ضمانت ہے، اور یہ صرف اس لیے ملتی ہے کیونکہ جانچنے کے لیے ایک دستاویز موجود ہے۔ منصوبہ ہٹا دیں تو پیمانہ بھی ہٹ جاتا ہے۔
یہاں یہ واقعی کہاں فائدہ دیتا ہے
بلڈ چلانے والے شخص کے طور پر آپ کی طاقت پہلے سے مرتکز ہوتی ہے، چاہے آپ اسے استعمال کریں یا نہیں۔ اگر آپ انفارمیشن آرکیٹیکچر، صفحے کی ساخت، کون سے فیچرز v1 بمقابلہ v2 میں جائیں گے کی فکر کرتے ہیں — تو یہ باریک بینی منصوبہ ریویو کے دوران پہلی جنریشن پاس کے بعد کے مقابلے میں دس گنا زیادہ قیمتی ہے۔ منصوبہ دوبارہ پڑھنے کے چار اضافی منٹ ایک ایسے بلڈ کو ٹھیک کرنے کے راؤنڈ ٹرپ سے بہتر ہیں جو پہلے سے بگڑ چکا ہو۔
سب سے واضح مثال پروڈکٹ کی قسم ہے — سادہ اسٹیٹک سائٹ، انسٹال ایبل ایپ، فریم ورک بلڈ، یا حقیقی پرسسٹنس کے ساتھ سرور-بیسڈ ایپ۔ یہ ڈراپ ڈاؤن لگتا ہے۔ ایسا نہیں ہے۔ یہ پورے عمل کا سب سے ساختی فیصلہ ہے، کیونکہ یہ خاموشی سے درجنوں چیزوں کا تعین کرتا ہے جن کا سائٹ کیسی نظر آتی ہے اس سے کوئی تعلق نہیں۔
| پروڈکٹ کی قسم | پیش منظر | شائع کریں | اکاؤنٹس / ڈیٹابیس |
|---|---|---|---|
| سادہ اسٹیٹک سائٹ | فوری، کیونکہ یہ محض اسٹیٹک فائلیں ہیں | اسٹیٹک آؤٹ پٹ صاف طریقے سے کاپی ہو جاتا ہے | ممکن نہیں — لاگ ان مانگنا اُس چیز کا مطالبہ ہے جو یہ قسم ساختی طور پر کر ہی نہیں سکتی |
| فریم ورک بلڈ | پہلے کمپائل ہوتا ہے؛ ٹوٹا بلڈ "کوئی پریویو نہیں" کے طور پر ظاہر ہوتا ہے، "خراب صفحہ" کے طور پر نہیں | کمپائل ہونے کے بعد وہی صاف اسٹیٹک-کاپی راستہ | ممکن نہیں |
| سرور-بیسڈ ایپ | — | کہیں ایسا مقام درکار ہوتا ہے جہاں پراسیس واقعی چل سکے، اور یہ مختلف طریقے سے ناکام ہوتا ہے — کریش شدہ پراسیس، غائب فائل نہیں | واحد قسم جس میں اکاؤنٹس اور ڈیٹابیس کا وجود ہی ممکن ہے |
اور آپ بعد میں نوعیت کو آرام سے اپ گریڈ نہیں کر سکتے۔ سادہ سائٹ سے سرور بیکڈ ایپ تک جانا کوئی سیٹنگز ٹوگل نہیں ہے — یہ تقریباً دوسری تعمیر کے برابر ہے، کیونکہ منصوبے کے آدھے مفروضے (پیجز کیسے لوڈ ہوتے ہیں، ڈیٹا کہاں رہتا ہے، "پبلش" کا کیا مطلب ہے) پرانی نوعیت کے حساب سے بنائے گئے تھے۔ تو منصوبہ بندی کے وقت ہی یہ بات کہیں، چاہے آدھے یقین کے ساتھ ہی: "ممکن ہے مجھے اکاؤنٹس کی ضرورت پڑے۔" سرور بیکڈ ایپ کے لیے منصوبہ بندی کر کے صرف اسٹیٹک حصے استعمال کرنا کچھ خرچ نہیں کرتا۔ بعد میں پتہ چلنا کہ آپ کو ایک کی ضرورت تھی، دوبارہ تعمیر کی قیمت چکاتا ہے۔
جہاں ناقدین کی بات درست ہے
یہ سب کچھ مفت نہیں ہے، اور میں یہ ظاہر نہیں کروں گا کہ ہے۔ ہر رن کے لیے الگ ورک اسپیس کا مطلب ہے کہ آپ کی نالج فائلیں ہر بار تازہ کاپی ہوتی ہیں، کچھ بھی واپس آپ کی مشین تک نہیں پہنچتا — یہ آپ کے لیے اچھا ہے اگر تعمیر کے دوران آپ کا لیپ ٹاپ خراب ہو جائے، لیکن لیٹنسی کے لیے برا ہے، کیونکہ ورک اسپیس فراہم کرنے اور، فریم ورک بلڈز کے لیے، کنٹینر باؤنڈری کے اندر ایک اصل ڈیپینڈنسی انسٹال چلانے میں حقیقی وقت لگتا ہے۔ یہ کنٹینر باؤنڈری اس لیے موجود ہے کیونکہ فریم ورک بلڈ `npm install` اور من مانے بلڈ اسکرپٹس چلاتا ہے — ایسا کوڈ جو آپ نے نہیں لکھا، جو بلڈ ٹائم مراعات کے ساتھ چلتا ہے — اور اسے شیئرڈ ہوسٹ پر بغیر آئسولیشن کے کرنا ایک ڈیپینڈنسی-کنفیوژن حملے کے فاصلے پر کسی اور ٹیننٹ کے ڈیٹا کو چھونے کے برابر ہے۔ تیز مگر غیر محفوظ کا آپشن موجود تھا۔ بس یہ کرنے کے قابل سودا نہیں تھا۔
تصدیق کے ساتھ بھی یہی کہانی ہے۔ مکمل شدہ تعمیر پائپ لائن کو اس وقت نہیں چھوڑتی جب جنریشن رکتی ہے؛ یہ اس وقت چھوڑتی ہے جب آزاد ویریفائرز کا ایک سیٹ ایسی چیزیں تلاش کرنا بند کر دے جو روکنے کے قابل ہوں:
- کوڈ ریویو
- سیکیورٹی
- لنکس اور SEO
- رسائی پذیری
- کنفارمنس
- براؤزر میں ایک اصل رن
یہ ایک پاس نہیں، بلکہ فلیگ-فکس-ری چیک ہے، جو اس وقت تک لوپ ہوتا ہے جب تک کسی کے پاس کہنے کو کچھ باقی نہ رہے، کیونکہ ایک ہی لنٹر پاس اپنی ہی فکس سے پیدا ہونے والی خرابی چھوڑ سکتا ہے۔ ایک ٹوٹا ہوا لنک ٹھیک کرتے ہوئے غلطی سے اسی صفحے پر ہیڈنگ کی درجہ بندی خراب کر دینا بالکل وہی چیز ہے جو ایک بار کی جانچ نظرانداز کرتی ہے اور ری چیک پکڑتا ہے۔ اس لوپ کی حقیقی قیمت وہ کبھی کبھار تعمیر ہے جو آخر میں بغیر کسی ظاہری وجہ کے ایک اضافی منٹ لیتی ہے۔ لوگ اس منٹ کو محسوس کرتے ہیں۔ وہ چھ ایجنٹس کو نہیں دیکھتے جنہوں نے ابھی ان کی سائٹ پر بحث ختم کی ہے۔ یہ تجربے کے بارے میں ایک جائز شکایت ہے — بس میں یہ نہیں سمجھتا کہ یہ اس بحث کے ہوئے بغیر شپ کرنے کی اچھی دلیل ہے۔



