کس طرح AI کلین کوڈ لکھنے کی معاشیات کو تبدیل کر رہا ہے۔

اگر آپ نے کبھی اپنے کوڈبیس میں انٹرفیس شامل کرنا چاہا ہے لیکن آپ کو پش بیک موصول ہوا ہے، تو آپ کو شاید پہلے ہی اس دلیل کا علم ہو جائے گا: "یہ ایک ہی چیز کا کوڈ سے دوگنا ہے۔”

اور ایمانداری سے؟ یہ ایک منصفانہ نقطہ تھا۔ آپ ایک معاہدہ لکھتے ہیں (انٹرفیس، خلاصہ کلاس، پروٹوکول) اور پھر ایک نفاذ لکھتے ہیں۔ ایک میں انجام دینے کے لیے دو فائلیں۔ اس میں زیادہ سطحی رقبہ، زیادہ انڈائریکشن، اور برقرار رکھنے کے لیے مزید چیزیں ہیں۔

روبی اور ریل کمیونٹیز نے اس کے ارد گرد پورے فلسفے بنائے ہیں۔ اس کا مطلب ہے کنفیگریشن، کم تقریب، اور کم کی اسٹروکس پر کنونشن کی پیروی کرنا۔ اگر فریم ورک آپ کے ارادے کا اندازہ لگا سکتا ہے، تو اس کی ہجے کیوں کریں؟

پھر AI ہوا۔

میں نے حال ہی میں ایک سی ای او کے ساتھ بات چیت کی تھی کہ سافٹ ویئر انجینئرز کی موجودہ نسل کیا غلط کر رہی ہے، اور اس نے واضح طور پر کہا:

"چند مہینے پہلے خلاصہ انٹرفیس مشکل تھے کیونکہ انہیں دو گنا زیادہ کوڈ کی ضرورت تھی۔ لیکن AI کے ساتھ، آپ کوڈ کی لائنیں خالی کرتے ہیں۔ ہمیں اب بھی ان تعمیرات کی ضرورت کی وجہ یہ ہے کہ کسی وقت، انسانوں کو ابھی بھی کوڈ کو دیکھنا پڑتا ہے۔ انٹرفیس علمی بوجھ کو کم کرتے ہیں۔”

وہ فریم میرے ساتھ پھنس گیا۔ کوڈ لکھنے کی قیمت ختم ہو گئی ہے۔ اسے پڑھنے کی قیمت میں کوئی حرکت نہیں ہوئی۔ اور یہ توازن ہر چیز کو بدل دیتا ہے کہ ہمیں تجرید کے بارے میں کیسے سوچنا چاہئے۔

میرا مطلب یہ ہے:

انڈیکس

آپ کا دماغ رکاوٹ ہے۔

یہ کوئی وائب بحث نہیں ہے۔ انٹرفیس کیوں مددگار ہیں اس کے پیچھے حقیقی نیورو سائنس ہے۔

1988 میں، تعلیمی ماہر نفسیات جان سویلر نے کوگنیٹو لوڈ تھیوری متعارف کرائی۔ 2022 کا ACM جائزہ بتاتا ہے کہ اس کے بعد سے اس کا اطلاق کمپیوٹنگ کی تعلیم پر کیسے ہوا ہے۔

سیدھے الفاظ میں، معلومات پر کارروائی کرتے وقت دماغ تین قسم کے بوجھ کو جھنجوڑتا ہے۔ ضروری بوجھ خود مسئلے کی موروثی مشکل ہے۔ خارجی لوڈنگ شور ہے۔ ناقص منظم معلومات، غیر ضروری تفصیلات، غلط نام۔ جرمن چھڑی اچھی چیز ہے۔ یہ دماغی کوشش ہے جو مفید ذہنی ماڈلز کی تعمیر پر خرچ ہوتی ہے۔

اہم نکات یہ ہیں: ورکنگ میموری ایک وقت میں معلومات کے صرف چند حصوں کو محفوظ کر سکتی ہے۔ علمی سائنس دان عام طور پر دو اور چھ کے درمیان تخمینہ لگاتے ہیں۔ 2-6 فائلیں یا 2-6 کلاسز نہیں بلکہ 2-6۔ وہ.

Felienne Hermans نے اس کی کھوج کی۔ پروگرامر کا دماغ (2021) دلیل دیتے ہیں کہ ڈیزائن کے نمونے چنکنگ ایڈز کے طور پر کام کرتے ہیں۔ ایک اسٹریٹجک پیٹرن کو تسلیم کرنے پر، دماغ پورے طبقاتی درجہ بندی کو ایک واحد علمی اکائی میں سمیٹ دیتا ہے۔ لفظ "حکمت عملی” پانچ طبقات اور ان کے تعلقات کی جگہ لے لیتا ہے۔ یہ صاف کوڈ کے بارے میں لہرانے کے بارے میں نہیں ہے۔ انسانی یادداشت دراصل اس طرح کام کرتی ہے۔

اور ہم اسے دماغی اسکین کے ذریعے لفظی طور پر دیکھ سکتے ہیں۔ 2021 میں، نارمن پیٹیک اور جینیٹ سیگمنڈ کی قیادت میں ایک ٹیم نے ICSE میں پروگرام کی فہمی کا ایک fMRI مطالعہ پیش کیا، جس نے ACM SIGSOFT بہترین پیپر ایوارڈ جیتا۔

انہوں نے ڈویلپرز کو دماغی سکینرز میں ڈالا اور دیکھا کہ کوڈ پڑھتے ہی کیا ہوا۔ دریافت: معنوی سطح پر تفہیم – فہم کیا کوڈ – باٹم اپ پارسنگ – ٹریکنگ سے بہت کم نیورل ایکٹیویشن کی ضرورت ہے۔ کس طرح یہ کرتا ہے۔

انٹرفیسز آپ کو ان کو معنوی سطح پر سمجھنے کی اجازت دیتے ہیں۔ UserRepository.findById(id) یہ آپ کو وہ سب کچھ بتاتا ہے جس کی آپ کو عمل درآمد کھولے بغیر جاننے کی ضرورت ہے۔ آپ کے دماغ کو ایس کیو ایل کے سوالات، کنکشن پول لاجک، ایرر ہینڈلنگ، اور کام کرنے والی میموری میں نتائج کو ایک ہی وقت میں میپ کرنے کی ضرورت نہیں ہے۔ انٹرفیس ہر چیز کو ایک ٹکڑے میں گاڑھا کرتا ہے۔

یہ خوبصورتی نہیں ہے۔ یہ نیورو سائنس ہے۔

عظیم لوگ پہلے ہی یہ جانتے تھے۔

تجرید کی مثالیں نئی ​​نہیں ہیں۔ کمپیوٹر سائنس کے بانی ہم میں سے اکثر کے پیدا ہونے سے پہلے ہی یہ دعوے کر رہے تھے۔

Dijkstra نے بالکل یہی کہا:

تجرید کا مقصد معنی کی ایک نئی سطح پیدا کرنا ہے جو مبہم ہونے کی بجائے مکمل طور پر درست ہو سکتا ہے۔

خلاصہ ان لوگوں سے مواد کو چھپانے کے بارے میں نہیں ہے جو پیچیدگی کو سنبھال نہیں سکتے ہیں۔ مقصد ایک ایسی سطح پر گفتگو کرنا ہے جو واضح استدلال کی اجازت دیتا ہو۔

ڈیوڈ پرناس نے 1972 کے ACM پیپر میں چھپی ہوئی معلومات کو باضابطہ شکل دی۔ "ہر ماڈیول کی خصوصیت ڈیزائن کے فیصلوں کے علم سے ہوتی ہے جو دوسرے تمام ماڈیولز میں پوشیدہ ہوتے ہیں۔” اس نے یہ ظاہر کیا کہ سسٹم کو ڈیزائن کے فیصلوں کے مطابق سڑنے سے اقدامات کرنے کے بجائے زیادہ لچکدار ماڈیولز نکلتے ہیں۔ اور یہ سمجھنا آسان ہے۔ فہم ایک بونس نہیں تھا، لیکن ڈیزائن کا معیار تھا۔

ٹونی ہوئر نے دلیل دی ہے کہ تجرید انسانی عقل کے لیے دستیاب سب سے طاقتور ٹول ہے: جو چیز اہم ہے اس پر توجہ مرکوز کرکے اور جو نہیں ہے اسے نظر انداز کرکے پیچیدگی کو منظم کرنے کا ایک طریقہ۔ مارٹن فولر نے اسے زندہ کر دیا۔

"کوئی بھی احمق کوڈ لکھ سکتا ہے جسے کمپیوٹر سمجھ سکتا ہے۔ ایک اچھا پروگرامر کوڈ لکھتا ہے جسے انسان سمجھ سکتا ہے۔”

اور پھر جان آسٹر ہاؤٹ کی کتاب ہے۔ سافٹ ویئر ڈیزائن کا فلسفہ (2018) واضح طور پر علمی بوجھ کے ساتھ ایک لنک تجویز کریں۔ اس کی بنیادی دلیل یہ ہے کہ کوڈ کی مزید لائنیں حقیقت میں ممکن ہیں۔ یہ آسان ہے اگر آپ علمی بوجھ کو کم کرتے ہیں۔

اس کا تصور ہے گہرائی سے ماڈیول – سادہ انٹرفیس جو پیچیدہ نفاذ کو چھپاتے ہیں – بنیادی طور پر، دلیل یہ ہے کہ کوڈ میں انٹرفیس اپنے وزن کے قابل ہیں۔ یونکس فائل سسٹم API (open, close, read, write, lseek) پانچ خصوصیات ہیں جو بہت زیادہ پیچیدگی کو چھپاتی ہیں۔ یہ ایک گہرا ماڈیول ہے۔ یہی مقصد ہے۔

گینگ آف فور نے اسے ایک وجہ سے کتاب میں پہلے رکھا۔ پہلا صفحہ: "انٹرفیس کے لیے پروگرامنگ، عمل درآمد نہیں۔”

اس میں سے کوئی بھی متنازعہ نہیں ہے۔ لیکن یہ بھولنا آسان ہے کہ ایک AI ٹول نے 3 سیکنڈ میں مکمل طور پر فعال ان لائن کوڈ کی 200 لائنیں تیار کیں۔

معیشت الٹ گئی۔

یہ وہ جگہ ہے جہاں سی ای او کی بصیرت ایک معاشی دلیل بن جاتی ہے۔

انٹرفیس کی تاریخی مثالیں ہمیشہ رہی ہیں۔ تحریری لاگت. انٹرفیس کا مطلب ہے لکھنے کے لیے زیادہ کوڈ، بنانے کے لیے مزید فائلیں، اور برقرار رکھنے کے لیے مزید بوائلر پلیٹ۔ ٹائپنگ کی پوری متحرک تحریک (Python, Ruby, JavaScript) جزوی طور پر جاوا جیسی زبانوں کے ذریعے نافذ کی جانے والی رسومات کا جواب تھا۔ تشکیل پر کنونشن۔ اپنے آپ کو نہ دہرائیں۔ کم زیادہ ہے۔

لیکن اپنے آپ سے پوچھیں: آج بوائلر پلیٹ لکھنے میں کتنا خرچ آتا ہے؟

GitHub کے 2022 کے کنٹرول شدہ مطالعے سے معلوم ہوا ہے کہ Copilot استعمال کرنے والے ڈویلپرز 55 فیصد تیزی سے کام مکمل کرتے ہیں۔ بوائلر پلیٹ کو اسکیپنگ انٹرفیس (اضافی فائلیں، قسم کی تعریفیں، طریقہ کار کے دستخط) کو جواز فراہم کرنے کے لیے استعمال کیا جاتا ہے، اسے تیار ہونے میں کئی سیکنڈ لگتے ہیں۔ انٹرفیس بنانے کی لاگت کو عملی طور پر صفر کر دیا گیا ہے۔

لیکن اس بار بھی پڑھنے کی فیس میں کمی نہیں آئی۔

رابرٹ سی مارٹن نے دلیل دی: صاف کوڈ (2008) نے پایا کہ ڈویلپرز کوڈ کو لکھنے سے زیادہ پڑھنے میں زیادہ وقت صرف کرتے ہیں۔ اس نے اسے 10:1 کے تناسب کے طور پر ظاہر کیا۔

اگرچہ صحیح تعداد سے پوچھ گچھ کی جا سکتی ہے (وہ قصہ پارینہ ہیں)، سمت تمام مطالعات میں یکساں ہے۔ ایک بڑے پیمانے پر فیلڈ اسٹڈی جس میں 78 پروفیشنل ڈویلپرز کو 3,148 گھنٹے تک ٹریک کیا گیا، پتہ چلا کہ انہوں نے اپنا تقریباً 58% وقت صرف پروگراموں کو سمجھنے میں صرف کیا۔ ایک نئے ڈویلپر کو آن بورڈ کرنے میں اوسطاً چھ ہفتے لگتے ہیں، اس میں زیادہ تر وقت نئے بنانے کی بجائے موجودہ سسٹم کو سمجھنے میں صرف ہوتا ہے۔

عدی عثمانی نے اس توازن کو بالکل ٹھیک نام دیا۔ مارچ 2026 کے ایک مضمون میں، اس نے وضاحت کی: سود کی ذمہ داری:

"جب ٹیم کے ڈویلپرز کوڈ لکھتے ہیں، تو انسانی جائزہ لینے کا عمل ہمیشہ ایک رکاوٹ رہا ہے، لیکن یہ نتیجہ خیز اور تعلیمی رہا ہے۔ PR پڑھنا سمجھ کو مضبوط کرتا ہے۔ AI سے تیار کردہ کوڈ فیڈ بیک لوپ کو توڑ دیتا ہے۔ حجم بہت زیادہ ہے۔”

آؤٹ پٹ صاف نظر آتا ہے، لنٹنگ سے گزرتا ہے، اور قواعد کی پیروی کرتا ہے۔ یہ بالکل وہی اشارہ ہے جس نے تاریخی طور پر انضمام کے اعتماد کو متحرک کیا۔ تاہم، فہم قرض تکنیکی قرض سے مختلف ہے کیونکہ یہ پوشیدہ طور پر جمع ہوتا ہے۔ سپیڈ میٹرکس، DORA سکور، اور PR نمبر سبھی اچھے لگ رہے ہیں، لیکن کوڈ بیس کے بارے میں ٹیم کی اصل سمجھ خاموشی سے ختم ہو رہی ہے۔

یہ ہے ریاضی: AI نے تجریدات لکھنے کی لاگت کو تقریباً صفر کر دیا ہے۔ خرچ ~ نہیں انسانی پڑھنے کا وقت، جہاز میں رگڑ، فہم قرض، وغیرہ میں کوئی تبدیلی نہیں آئی ہے۔ بریک ایون پوائنٹ "کیا یہ انٹرفیس اس کے قابل ہے؟” ابھی "ہاں” کے حق میں بڑی تبدیلی کی ہے۔

ڈیٹا اس کا بیک اپ لیتا ہے۔

یہ نظریاتی نہیں ہے۔ اس بارے میں ڈیٹا موجود ہے کہ جب AI اچھے تجرید کے بغیر کوڈ تیار کرتا ہے تو کیا ہوتا ہے۔

GitClear نے کوڈ کی 211 ملین لائنوں کا تجزیہ کیا جو 2020 اور 2024 کے درمیان تبدیل ہوئے۔ نتائج: کوڈ چرن (لائنز کو دو ہفتوں کے اندر تبدیل یا اپ ڈیٹ کیا گیا) پری AI بیس لائن کے مقابلے میں دوگنا ہو گیا۔ کاپی اور پیسٹ شدہ کوڈ بلاکس 8.3% سے بڑھ کر 12.3% ہو گئے۔ اور ری فیکٹرنگ سے متعلق تبدیلیاں 25% سے کم ہو کر 10% سے کم ہو گئیں۔

AI سے تیار کردہ کوڈ، جیسا کہ انہوں نے کہا ہے، "ایک عبور کرنے والے شراکت دار کی طرح ہے جو ملاحظہ کردہ ذخیروں کے DRY-ness کی خلاف ورزی کا شکار ہے۔”

METR مطالعہ (2025) نے کچھ اور بھی حیران کن پایا۔ تجربہ کار اوپن سورس ڈویلپر پیشن گوئی AI انہیں 24% تیز کر دے گا۔ انہیں سمجھا استعمال کے دوران 20% تیزی سے حاصل کریں۔ حقیقت میں، یہ 19 فیصد سست تھا۔ ادراک میں فرق کہانی ہے – آپ محسوس آپ کوڈ تیار کرتے ہوئے اپنی پیداواری صلاحیت کو بڑھا سکتے ہیں جو نیچے کی طرف مزید کام کرتا ہے۔

اور یہاں انتھروپک کی طرف سے ایک مطالعہ ہے (ہاں، وہ کمپنی جو کلاڈ بناتی ہے — مکمل انکشاف)۔ انہوں نے 52 سافٹ ویئر انجینئرز کو ایک نئی لائبریری سیکھنے کا مشاہدہ کیا۔ AI کی مدد سے گروپ نے کام کو اسی رفتار سے مکمل کیا لیکن بعد میں ہونے والے فہمی کوئز (50% بمقابلہ 67%) میں 17% کم اسکور کیا۔ سب سے بڑی کمی ڈیبگنگ کی صلاحیت میں تھی۔ آپ کوڈ بھیج سکتے ہیں جو آپ کو سمجھ نہیں آتا ہے۔ آپ کوڈ کو ڈیبگ نہیں کر سکتے جو آپ نہیں سمجھتے ہیں۔

کینٹ بیک نے اسے دو ٹوک الفاظ میں کہا: "میری 90% مہارتوں کی قدر $0 تک گر گئی۔ بقیہ 10% پر لیوریج 1000x بڑھ گئی۔” بقیہ 10% جان بوجھ کر کھلا چھوڑ دیا گیا ہے۔ لیکن سسٹم کے ڈیزائن کے بارے میں سوچے بغیر پڑھنا مشکل ہے۔

کے خلاف مقدمہ (اور آپ اصل میں کیوں متفق ہیں)

اگر میں تجرید کی مخالفت کرنے والوں کو مخاطب نہ کروں تو میں بے ایمانی کروں گا۔ اور ان میں سے کچھ بہت ہوشیار ہیں۔

کیسی موراٹوری کے "کلین کوڈ، ٹیریبل پرفارمنس” نے ظاہر کیا کہ پولیمورفزم اور ورچوئل ڈسپیچ کوڈ کو سادہ طریقہ کار کے متبادل سے 10 سے 15 گنا سست بنا سکتے ہیں۔

اس کے معیارات حقیقی ہیں۔ اگر آپ گیم انجن یا ہائی فریکوئنسی ٹریڈنگ سسٹم لکھ رہے ہیں، تو ہاٹ پاتھ کا خلاصہ انٹرفیس اسے مہنگا بنا دیتا ہے۔

ڈین ابراموف نے "الوداع، کلین کوڈ” یہ دیکھنے کے بعد لکھا کہ کس طرح قبل از وقت تجریدات نے کوڈ بیسز کو تبدیل کرنا مشکل بنا دیا۔

"میرے کوڈ نے ایسی خصوصیات کی تجارت کی جس نے کم نقل کی ضروریات کو تبدیل کیا، جو کہ اچھا سودا نہیں تھا۔”

سینڈی میٹز نے اسے اور بھی واضح طور پر کہا: "ایک خراب تجرید سے نقل کرنا بہت سستا ہے۔”

رچ ہکی نے اپنی گفتگو "سادہ آسان” میں درج ذیل اہم امتیازات بیان کیے ہیں: سادہ (غیر الجھا ہوا) ایک جیسا نہیں ہے: آسان (آشنا) برا خلاصہ واٹر ٹائٹ – وہ خدشات کو الگ کرنے کے بجائے ایک دوسرے کے ساتھ باندھتے ہیں۔

مسئلہ یہ ہے کہ: ان میں سے کوئی بھی تجرید کے خلاف دلیل نہیں ہے۔ وہ اس کے برعکس بحث کر رہے ہیں برا نکالنا

Muratori کی کارکردگی کے دعوے کارکردگی کے اہم نظاموں میں گرم راستوں پر لاگو ہوتے ہیں، REST APIs کی سروس پرت پر نہیں۔ ابراموف اور میٹز اس کے خلاف ہیں۔ کروکر خلاصہ – ڈومین کو سمجھنے سے پہلے پیٹرن نکالنا۔ اور ہکی کی پوری کہانی صرف ایک مثال ہے۔ کے لیے صحیح تجرید، یعنی ایک تجرید جو واقعی پیچیدگیوں کے بجائے گل جاتا ہے۔

ستم ظریفی یہ ہے کہ AI سے چلنے والی دنیا میں، یہ دعوے ہیں: زیادہ آسانی سے پتہ بتا دیں۔ سب سے پہلے، آپ ایک واضح، غیر تجریدی ورژن بنا سکتے ہیں۔ مستحکم کرنا۔ یہ دیکھنے کے لیے دیکھیں کہ آیا کوئی پیٹرن ابھرتا ہے۔ AI پھر تجریدات کو نکالنے کے لیے مکینیکل ری فیکٹرنگ کو سنبھالتا ہے۔ "پہلے نقل تیار کریں، بعد میں تجریدی” نقطہ نظر کی لاگت تقریباً صفر تک گر گئی ہے۔

آپ کے لیے اس کا کیا مطلب ہے۔

اگر آپ AI ٹول کا استعمال کرتے ہوئے کوڈ لکھ رہے ہیں (ہم میں سے زیادہ تر لوگ اس وقت ہیں)، تو یہ پرکشش ہے کہ AI جو کچھ بھی پیدا کرتا ہے اسے تیار کریں اور آگے بڑھیں۔ یہ کام کرتا ہے۔ ٹیسٹ پاس ہو گیا۔ براہ کرم پہنچا دیں۔

لیکن "یہ کام کرتا ہے” ٹیبل اسٹیک ہے۔ مشکل سوال یہ ہے کہ کیا اس کوڈ کو کھولنے والا اگلا شخص اسے 5 منٹ میں سمجھ سکے گا؟ کر سکتے ہیں آپ آپ کو 6 ماہ میں پتہ چل جائے گا، ٹھیک ہے؟

انٹرفیسز کوڈ کو خوبصورت بنانے یا تجریدی (پن کا مقصد) ڈیزائن کے اصولوں کو مطمئن کرنے کے بارے میں نہیں ہیں۔ انسانی ادراک کے لیے ایک کمپریشن الگورتھم۔ وہ آپ کے دماغ کو نحوی سطح کے بجائے سیمنٹک سطح پر کام کرنے پر مجبور کرتے ہیں۔ اور اب جب کہ AI نے بوائلر پلیٹ کو ختم کر دیا ہے، جو اسے بنانے کی واحد اصل قیمت ہے، اس کو چھوڑنے کے لیے کوئی معاشی دلیل باقی نہیں رہی ہے۔

قوانین تبدیل نہیں ہوئے ہیں۔ عذر ابھی ختم ہوا ہے۔

حوالہ جات

تعلیمی کاغذ

• Duran, R., Zavgorodnia, A., & Sorva, J. (2022)۔ "کمپیوٹنگ ایجوکیشن ریسرچ میں سنجشتھاناتمک بوجھ تھیوری: ایک جائزہ۔” کمپیوٹنگ ایجوکیشن پر ACM ٹرانزیکشنز، 22(4)، آرٹیکل 40۔

• پرناس، ڈی ایل (1972)۔ "کسی نظام کو ماڈیولز میں تحلیل کرنے کے لیے استعمال ہونے والے معیار پر۔” ACM کمیونیکیشنز، 15(12)، 1053-1058۔

• Peitek, N., Apel, S., Parnin, C., Brechmann, A., & Siegmund, J. (2021)۔ "پروگرام کی سمجھ اور کوڈ کی پیچیدگی کی پیمائش: ایک ایف ایم آر آئی مطالعہ۔” آئی سی ایس ای 2021. ACM SIGSOFT بہترین پیپر ایوارڈ۔

• Peng, S. Kalliamvakou, E., Cihon, P., & Demirer, M. (2023)۔ "ڈیولپر کی پیداواری صلاحیت پر AI کا اثر: GitHub Copilot سے ثبوت۔” arXiv:2302.06590.

• شین، جے ایچ اور تمکن، اے (2026)۔ "ٹیکنالوجی کی تشکیل پر AI کا اثر۔” arXiv:2601.20245.

• Xia, X., Bao, L., Lo, D., Xing, Z., Hassan, A. E., & Li, S. (2018)۔ "میجرنگ پروگرام کی تفہیم: ماہرین کے ساتھ ایک بڑے پیمانے پر فیلڈ اسٹڈی۔” سافٹ ویئر انجینئرنگ پر IEEE ٹرانزیکشنز، 44(10)، 951-976۔

• میٹر (2025)۔ "2025 کے اوائل میں ہنر مند اوپن سورس ڈویلپر کی پیداواری صلاحیت پر AI کے اثرات کی پیمائش۔” metr.org.

لیکچرز اور بلاگ پوسٹس