ہر نیا پروجیکٹ ایک ہی وسوسہ جگاتا ہے: ایڈیٹر کھولیں، ایک فریم ورک منتخب کریں، اور ٹائپ کرنا شروع کر دیں۔ MaxOS کے لیے، اس کے تخلیق کار Max Paardekam نے اس کشش کو شدت سے محسوس کیا۔ چند ہفتے پہلے تک، یہ پروجیکٹ صرف ان کے نوٹس میں بکھرے ہوئے خیالات کی صورت میں تھا۔ ان کی فوری جبلت تھی کہ وہ Cursor کے اندر گھنٹوں TypeScript لکھنے میں گزاریں، تاکہ مسل میموری اور آٹو کمپلیٹ کے ذریعے کام میں تیزی آ سکے۔ لیکن انہوں نے اس کی مزاحمت کی۔ ایپلی کیشن کوڈ کے بجائے، انہوں نے کچھ ایسا تیار کیا جو زیادہ نایاب اور نازک تھا: ایک مکمل آرکیٹیکچر۔
شروع میں یہ فیصلہ جمود محسوس ہوا۔ جب ٹولز تیار ہوں اور بوائلر پلیٹ سیکنڈوں میں انسٹال ہو جائے، تو ڈبے اور تیر (boxes and arrows) بنانے کے لیے رکنا بے معنی لگ سکتا ہے۔ لیکن MaxOS کوئی عام ویب ویو کے گرد بنا ہوا Electron wrapper بننے کے لیے نہیں تیار ہو رہا۔ اس کا مقصد کچھ ایسا بنانا ہے جو برسوں کے استعمال، ریفیکٹرنگ اور توسیع کے بعد بھی قائم رہے۔ اس طرح کی عمر والے نظاموں کو فوری آغاز سے کہیں زیادہ گہری چیز کی ضرورت ہوتی ہے۔ انہیں پہلے 'امپورٹ سٹیٹمنٹ' سے پہلے مربوط سوچ کی ضرورت ہوتی ہے۔
IDE کیوں انتظار کر سکتا ہے
جدید ڈویلپمنٹ ماحول منصوبہ بندی اور عمل درآمد کے درمیان فرق کو ختم کر دیتے ہیں۔ Cursor اور اس جیسے AI کی مدد سے چلنے والے ایڈیٹرز ایک کمنٹ سے پورے کمپوننٹس تیار کرنا ممکن بنا دیتے ہیں۔ فیڈ بیک کا عمل فوری ہوتا ہے، اور ایک UI کو حقیقت میں بدلتے ہوئے دیکھنے سے ملنے والا ڈوپامائن کا اثر (dopamine hit) مقابلہ کرنے میں مشکل ہوتا ہے۔ Paardekam نے بالکل اسی مفروضے کے ساتھ آغاز کیا تھا: ان کی ابتدائی توانائی کا زیادہ تر حصہ براہ راست TypeScript فائلوں میں جائے گا۔ تاہم، انہوں نے رفتہ رفتہ ان دنوں کو خالص ڈیزائن کے کام کی طرف موڑ دیا۔
کسی بھی اکیلے ڈویلپر کے لیے یہ ایک مشکل تبدیلی ہے۔ جب آپ ہی اپنی پوری انجینئرنگ ٹیم ہوں، تو ڈائیگرام ٹول یا ٹیکسٹ ڈاکومنٹ میں گزارا گیا ہر گھنٹہ ایسا لگتا ہے جیسے پروڈکٹ لانچ کرنے کے وقت سے چوری کیا گیا ہو۔ لیکن ابتدائی کوڈ اکثر ترقی کے لبادے میں چھپا ہوا ایک بوجھ ہوتا ہے۔ ایک چلتے ہوئے پروٹو ٹائپ کی نویت (novelty) جلد ختم ہو جاتی ہے جب ہر نیا فیچر ان مفروضوں کے گرد گھومنے کی ضرورت پڑتی ہے جو پہلے ہی پہلے دن طے کر لیے گئے ہوں۔ ایڈیٹر سے خود کو دور رکھ کر، Paardekam نے وہ واحد اثاثہ حاصل کیا جو وقت کے ساتھ بڑھتا ہے: وضاحت (clarity)۔
فیچرز کے بجائے سسٹم کے بارے میں سوچنا
ان ہفتوں کے دوران سب سے بڑی تبدیلی تکنیکی نہیں تھی۔ یہ ادراکی (cognitive) تھی۔ سافٹ ویئر آرکیٹیکچر، جب اسے سنجیدگی سے لیا جائے، تو یہ آپ کے سوالات کرنے کے انداز کو بدل دیتا ہے۔ Paardekam نے پروجیکٹ کو فیچر کی سوچ کے ساتھ دیکھنا بند کر دیا۔ وہ اب یہ نہیں پوچھ رہے تھے کہ کسی خاص صلاحیت کو کیسے جوڑا جائے، بلکہ انہوں نے ایک مشکل سوال کا سامنا کیا: وہ بنیادی ڈھانچہ کیا ہوگا جو ہر مستقبل کی صلاحیت کو شامل کرنا آسان بنا دے گا؟
یہ فرق اہمیت رکھتا ہے۔ فیچر کی سوچ سافٹ ویئر کے ساتھ ایک 'ٹو-ڈو لسٹ' کی طرح پیش آتی ہے۔ آپ پہلے سرچ، پھر نوٹیفیکیشنز، اور پھر ایکسپورٹ بٹن نافذ کرتے ہیں۔ سسٹم کی سوچ یہ پوچھتی ہے کہ سرچ، نوٹیفیکیشنز اور ایکسپورٹس ایک ہی ڈیٹا ماڈل، ایک ہی ایونٹ بس اور ایک ہی پرمیشن لیئر کو کیسے استعمال کر سکتے ہیں۔ اس کا مطلب ہے کہ جملے لکھنے سے پہلے ایپلی کیشن کی گرامر ڈیزائن کرنا۔ اس کی ابتدائی لاگت زیادہ ہے۔ لیکن انعام یہ ہے کہ مستقبل کا کام محض جوڑ توڑ (assembly) محسوس نہیں ہوتا بلکہ ایک تخلیقی ترتیب (composition) محسوس ہوتا ہے۔
یہ MaxOS جیسے پروجیکٹ کے لیے خاص طور پر اہم ہے، جس کا مقصد ان فنکشنز کو ضم کرنا ہے جو عام طور پر دس مختلف ایپلی کیشنز کے اندر ہوتے ہیں۔ سسٹیمیٹک سوچ کے بغیر گہرا انٹیگریشن کمزور پلوں اور غیر مستقل حالت (inconsistent state) کا ڈراؤنا خواب بن جاتا ہے۔ اس کے ساتھ، ورک سپیس مختلف ٹولز کے مجموعے کے بجائے ایک واحد جاندار کی طرح کام کرتا ہے۔
ورک سپیس، آپریٹنگ سسٹم نہیں
Paardekam اپنے مقصد کی حدود کے بارے میں بالکل واضح رہے ہیں۔ MaxOS، Windows یا macOS کی جگہ نہیں لے گا۔ یہ ڈرائیورز، میموری الاکیشن، یا ہارڈ ویئر ایبسٹریکشن لیئرز کو سنبھالنے کی خواہش نہیں رکھتا۔ اس کا ہدف کچھ زیادہ ہی قریبی ہے: ورک سپیس۔
زیادہ تر نالج ورکرز ایک ٹوٹے پھوٹے ماحول میں رہتے ہیں۔ آپ ای میل کلائنٹ سے کیلنڈر پر، نوٹس ایپ سے ٹرمینل پر، ڈیزائن ٹول سے میسجنگ پلیٹ فارم پر جاتے ہیں۔ ہر بار اس تبدیلی میں رکاوٹ آتی ہے۔ سیاق و سباق (context) کھو جاتا ہے۔ توجہ بکھر جاتی ہے۔ آپریٹنگ سسٹم اسٹیج فراہم کرتا ہے، لیکن وہ ڈرامہ ڈائریکٹ نہیں کرتا۔
MaxOS کا ارادہ اس تجربے کو ایک ایسے ماحول میں یکجا کرنا ہے جو آپ کے کام کے تسلسل کو سمجھے اور آپ کو تیزی سے آگے بڑھنے میں مدد دے۔ یہ ایک روایتی OS بنانے کے مقابلے میں ایک مختلف انجینئرنگ چیلنج ہے۔ اس کے لیے ورک فلو کے لیے گہری ہمدردی، دائرہ کار کی سخت ایڈیٹنگ، اور ایسے انٹرفیسز کی ضرورت ہے جو صارف کو ٹول کے مطابق ڈھالنے کے بجائے صارف کے ارادے کے مطابق خود کو ڈھال لیں۔ ورک سپیس کو تبدیل کرنے کا مطلب ہے عادات کو تبدیل کرنا، اور عادات صرف تب بدلتی ہیں جب متبادل چیز سیکھنے کے مشکل مرحلے کے بجائے ایک ریلیف محسوس ہو۔
خاموش ہفتوں میں کیا تعمیر ہوا
Paardekam کے آرکیٹیکچر کے مرحلے نے دو ٹھوس نتائج فراہم کیے۔ پہلا، وژن اور مشن کی واضح تعریف۔ یہ محض مارکیٹنگ کی فضول باتیں نہیں ہیں۔ ایک تنہا تکنیکی بانی (solo technical founder) کے لیے، یہ اسکوپ کے محافظ کے طور پر کام کرتا ہے۔ جب آپ کو یہ فیصلہ کرنا ہو کہ چیٹ سائیڈ بار یا پلگ ان مارکیٹ پلیس شامل کرنی ہے یا نہیں، تو مشن کا بیان یا تو اسے خوش آمدید کہتا ہے یا اسے مسترد کر دیتا ہے۔ دوسرا، اس نے پروجیکٹ کا مکمل بلیو پرنٹ (خاکہ) مکمل کیا۔
پورے منصوبے کو شروع سے آخر تک پھیلا ہوا دیکھنا پروجیکٹ کی نفسیات کو بدل دیتا ہے۔ نوٹ بکس میں موجود آئیڈیاز فرضی محسوس ہوتے ہیں۔ ایک بلیو پرنٹ ناگزیر محسوس ہوتا ہے۔ یہ ان خامیوں کو ظاہر کر دیتا ہے جب انہیں ٹھیک کرنا ابھی سستا ہو۔ یہ ان جگہوں کو بے نقاب کرتا ہے جہاں مشکل ترین خطرات چھپے ہوتے ہیں۔ اس مرحلے پر، ایک درست دستاویز کوڈ کی لائنوں سے کہیں زیادہ اہمیت رکھتی ہے۔ کوڈ کو ریفیکٹر (refactor) کیا جا سکتا ہے؛ لیکن ایک غیر واضح بنیاد ایک ایسے تکنیکی قرض (technical debt) میں بدل جاتی ہے جسے راتوں کو کی جانے والی ڈی بگنگ (debugging) بھی ختم نہیں کر سکتی۔
کاغذ سے مونو ریپو (Monorepo) تک
آرکیٹیکچر مکمل ہونے کے ساتھ ہی اگلا مرحلہ شروع ہو گیا ہے۔ Paardekam دستاویزات سے کوڈ کی طرف بڑھ رہا ہے، جس کا آغاز مونو ریپو (monorepo) کی شروعات (initialization) سے ہو رہا ہے۔ یہ تبدیلی اپنے ساتھ ایک بے چینی لاتی ہے۔ بلیو پرنٹ ایک وعدہ ہے۔ کوڈ بیس (codebase) ایک ثبوت ہے۔ اس نے اعتراف کیا ہے کہ وہ اس بات کے بارے میں گھبراہٹ محسوس کر رہا ہے کہ آیا ڈیزائن عملدرآمد (implementation) کے مرحلے میں برقرار رہ پائے گا یا نہیں۔ یہ ایمانداری ان نامعلوم عوامل کے لیے ایک صحت مند احترام کی عکاس ہے جو صرف اس وقت سامنے آتے ہیں جب تھیوری، لائبریری کے ورژنز، ایج کیسز (edge cases) اور کراس پلیٹ فارم رویوں کی حقیقتوں سے ٹکراتی ہے۔
مونو ریپو کو انیشلائز (initialize) کرنا محض ایک رسمی git init سے بڑھ کر ہے۔ یہ وہ مادی ڈھانچہ ترتیب دیتا ہے جو منطقی آرکیٹیکچر کی عکاسی کرے گا۔ پیکیجز کہاں ہوں گے، وہ ایک دوسرے پر کیسے انحصار کریں گے، اور لیئرز کے درمیان حدود کہاں ہوں گی، یہ سب ہفتوں کی منصوبہ بندی کا عکس ہوگا۔ اگر اسے بہتر طریقے سے کیا جائے تو پہلا فولڈر اسٹرکچر اور بلڈ پائپ لائن (build pipeline) مستقبل کی شراکت میں رہنمائی کرے گی۔ اگر اسے ناقص طریقے سے کیا گیا، تو یہ برسوں تک ہر اس ڈویلپر کو خاموشی سے سزا دے گا جو اس پروجیکٹ پر کام کرے گا۔
اصل سبق
Paardekam کا تجربہ اس 'رفتار کے جنون' (cult of velocity) کے خلاف ہے جو جدید سافٹ ویئر کلچر پر حاوی ہے۔ تیزی سے چیزیں لانچ کرنے، ترقی دکھانے، اور کوڈ کو گفتگو کی جگہ دینے کا شدید دباؤ ہوتا ہے۔ لیکن کچھ پروجیکٹس، خاص طور پر وہ جو دیرپا رہنے کے لیے بنائے جاتے ہیں، صبر کا پھل دیتے ہیں۔ اپنے وژن کی تعریف کرنا، اپنے بلیو پرنٹ کا نقشہ بنانا، اور اپنے ویری ایبلز (variables) کا اعلان کرنے سے پہلے اپنے سسٹم کو ڈیزائن کرنے کا نظم و ضبط ایک پرانی نصیحت ہے جو کبھی غلط نہیں ہوئی۔
اگر آپ اس وقت کسی آئیڈیا پر بیٹھے ہیں اور اپنا ایڈیٹر کھولنے کے لیے بے تاب ہیں، تو اس بات پر غور کریں کہ کیا چند دن کی سوچ سمجھی ڈیزائننگ آپ کو مہینوں کی بکھری ہوئی دوبارہ محنت سے بچا سکتی ہے۔ چلتی ہوئی ایپ کا ڈوپامین (dopamine) ختم ہو جاتا ہے۔ ایک اچھے آرکیٹیکچر کی وضاحت وقت کے ساتھ ساتھ بڑھتی جاتی ہے۔ اس بات کو جان کر شروع کریں کہ آپ اصل میں کیا بنا رہے ہیں اور کیوں۔ ٹائپنگ کا کام انتظار کر سکتا ہے۔