جامد کوڈ تجزیہ کار کو آزمانا آسان ہے۔ لیکن اسے لاگو کرنے کے لیے، خاص طور پر ایک بڑے پرانے منصوبے کی ترقی میں، مہارت کی ضرورت ہوتی ہے۔ اگر غلط طریقے سے کیا جاتا ہے تو، تجزیہ کار کام کو شامل کر سکتا ہے، ترقی کو سست کر سکتا ہے، اور ٹیم کو کم کر سکتا ہے۔ آئیے مختصراً اس کے بارے میں بات کرتے ہیں کہ ترقی کے عمل میں جامد تجزیہ کے انضمام کو کیسے مناسب طریقے سے استعمال کیا جائے اور اسے CI/CD کے حصے کے طور پر استعمال کرنا شروع کیا جائے۔
تعارف
حال ہی میں میری توجہ اشاعت کی طرف مبذول کرائی گئی۔"ایک طرف، یہ ایک اچھا مضمون ہے جس سے واقف ہونے کے قابل ہے۔ دوسری طرف، مجھے لگتا ہے کہ یہ اب بھی مکمل جواب فراہم نہیں کرتا ہے کہ کسی پروجیکٹ میں جامد تجزیہ کو بغیر کسی تکلیف کے کیسے لاگو کیا جائے۔ میراثی کوڈ کا مضمون کہتا ہے کہ آپ تکنیکی قرض قبول کر سکتے ہیں اور صرف نئے کوڈ پر کام کر سکتے ہیں، لیکن اس تکنیکی قرض کا بعد میں کیا کرنا ہے۔
ہماری PVS-Studio ٹیم اس موضوع پر اپنا نقطہ نظر پیش کرتی ہے۔ آئیے دیکھتے ہیں کہ جامد کوڈ اینالائزر کو لاگو کرنے کا مسئلہ سب سے پہلے کس طرح پیدا ہوتا ہے، اس مسئلے پر کیسے قابو پایا جائے، اور تکنیکی قرضوں کو بتدریج کیسے ختم کیا جائے۔
مسائل
یہ عام طور پر شروع کرنا اور دیکھنا مشکل نہیں ہے کہ جامد تجزیہ کار کیسے کام کرتا ہے [] آپ کوڈ میں دلچسپ غلطیاں یا خوفناک ممکنہ کمزوریاں بھی دیکھ سکتے ہیں۔ یہاں تک کہ آپ کچھ ٹھیک کر سکتے ہیں، لیکن پھر بہت سے پروگرامرز ترک کر دیتے ہیں۔
تمام جامد تجزیہ کار غلط مثبت پیدا کرتے ہیں۔ یہ جامد کوڈ تجزیہ کے طریقہ کار کی ایک خصوصیت ہے، اور اس کے بارے میں کچھ نہیں کیا جا سکتا۔ عام صورت میں، یہ ایک ناقابل حل مسئلہ ہے، جیسا کہ رائس کے تھیوریم سے تصدیق ہوتی ہے۔] مشین لرننگ الگورتھم بھی مدد نہیں کریں گے] یہاں تک کہ اگر کوئی شخص ہمیشہ یہ نہیں بتا سکتا کہ آیا یہ یا وہ کوڈ غلط ہے، تو آپ کو پروگرام سے اس کی توقع نہیں کرنی چاہیے :)۔
اگر جامد تجزیہ کار پہلے سے تشکیل شدہ ہے تو غلط مثبت کوئی مسئلہ نہیں ہے:
- غیر متعلقہ اصولوں کے سیٹ غیر فعال
- کچھ غیر متعلقہ تشخیص کو غیر فعال کر دیا گیا ہے۔
- اگر ہم C یا C++ کے بارے میں بات کر رہے ہیں، تو میکرو کو نشان زد کیا جاتا ہے جو مخصوص تعمیرات پر مشتمل ہوتے ہیں جس کی وجہ سے ہر اس جگہ پر جہاں اس طرح کے میکرو استعمال ہوتے ہیں، بیکار وارننگ ظاہر ہوتے ہیں۔
- اپنے فنکشنز کو نشان زد کیا گیا ہے جو سسٹم فنکشنز (اس کا اپنا اینالاگ) کی طرح کام انجام دیتے ہیں۔ میمسی یا پرنف) [];
- غلط مثبت کو خاص طور پر تبصروں کا استعمال کرتے ہوئے غیر فعال کر دیا جاتا ہے۔
- اور اسی طرح کی.
اس صورت میں، ہم تقریباً 10-15% کی کم جھوٹی مثبت شرح کی توقع کر سکتے ہیں۔] دوسرے لفظوں میں، 9 میں سے 10 تجزیہ کار انتباہات کوڈ میں ایک حقیقی مسئلہ، یا کم از کم "تیز بو والے کوڈ" کی نشاندہی کریں گے۔ متفق ہوں، یہ منظر انتہائی خوشگوار ہے، اور تجزیہ کار پروگرامر کا حقیقی دوست ہے۔
حقیقت میں، ایک بڑے منصوبے میں، ابتدائی تصویر بالکل مختلف ہو جائے گا. تجزیہ کار لیگیسی کوڈ کے لیے سینکڑوں یا ہزاروں وارننگ جاری کرتا ہے۔ فوری طور پر یہ سمجھنا ناممکن ہے کہ ان میں سے کون سی انتباہات متعلقہ ہیں اور کون سی نہیں۔ ان تمام انتباہات سے نمٹنا شروع کر دینا غیر معقول ہے، کیونکہ اس معاملے میں اہم کام دنوں یا ہفتوں تک رک جائے گا۔ عام طور پر، ایک ٹیم اس طرح کے منظر نامے کی متحمل نہیں ہو سکتی۔ تبدیلی کی تاریخ کو خراب کرنے والے اختلافات کی ایک بڑی تعداد بھی ہوگی۔ اور کوڈ میں بہت سارے ٹکڑوں کی تیزی سے بڑے پیمانے پر ترمیم کے نتیجے میں لامحالہ نئی ٹائپوز اور غلطیاں پیدا ہوں گی۔
اور سب سے اہم بات یہ ہے کہ انتباہات کے خلاف جنگ میں اس طرح کا کارنامہ بہت کم معنی رکھتا ہے۔ اس بات سے اتفاق کرتے ہیں کہ چونکہ یہ منصوبہ کئی سالوں سے کامیابی سے چل رہا ہے، اس لیے اس میں موجود زیادہ تر اہم خرابیوں کو پہلے ہی درست کر دیا گیا ہے۔ ہاں، یہ اصلاحات بہت مہنگی تھیں، انہیں ڈیبگ کرنا پڑا، کیڑے کے بارے میں صارف کی منفی رائے موصول ہوئی، وغیرہ۔ ایک جامد تجزیہ کار کوڈنگ کے مرحلے پر ان میں سے بہت سی غلطیوں کو جلدی اور سستے طریقے سے ٹھیک کرنے میں مدد کرے گا۔ لیکن اس وقت، کسی نہ کسی طریقے سے، ان غلطیوں کو ٹھیک کر دیا گیا ہے، اور تجزیہ کار بنیادی طور پر پرانے کوڈ میں غیر اہم غلطیوں کا پتہ لگاتا ہے۔ یہ کوڈ استعمال نہیں کیا جا سکتا ہے، یہ بہت کم استعمال کیا جا سکتا ہے، اور اس میں ایک غلطی قابل ذکر نتائج کی قیادت نہیں کر سکتی ہے. شاید کہیں بٹن سے سایہ غلط رنگ ہو، لیکن یہ کسی کے پروڈکٹ کے استعمال میں مداخلت نہیں کرتا۔
بلاشبہ، معمولی غلطیاں بھی غلطیاں ہیں۔ اور بعض اوقات ایک غلطی ایک حقیقی خطرے کو چھپا سکتی ہے۔ تاہم، ہر چیز کو ترک کرنا اور ان نقائص سے نمٹنے کے لیے دن/ہفتے گزارنا جو بمشکل خود کو ظاہر کرتے ہیں ایک مشکوک خیال کی طرح لگتا ہے۔
پروگرامرز پرانے ورکنگ کوڈ کے بارے میں ان تمام انتباہات کو دیکھتے ہیں، دیکھیں، دیکھیں... اور وہ سوچتے ہیں: ہم جامد تجزیہ کے بغیر کر سکتے ہیں۔ چلیں کچھ نئی مفید فعالیت لکھتے ہیں۔
اپنے طریقے سے، وہ درست ہیں۔ وہ سمجھتے ہیں کہ پہلے انہیں ان تمام انتباہات سے کسی طرح چھٹکارا حاصل کرنا ہوگا۔ تب ہی وہ کوڈ اینالائزر کے باقاعدہ استعمال سے فائدہ اٹھا سکیں گے۔ دوسری صورت میں، نئی انتباہات صرف پرانی میں ڈوب جائیں گے، اور کوئی بھی ان پر توجہ نہیں دے گا.
یہ وہی مشابہت ہے جو کمپائلر وارننگز کے ساتھ ہے۔ یہ بلا وجہ نہیں ہے کہ وہ کمپائلر وارننگز کی تعداد 0 پر رکھنے کا مشورہ دیتے ہیں۔ اگر 1000 وارننگز ہیں، تو جب 1001 ہوں گے تو کوئی اس پر توجہ نہیں دے گا، اور یہ واضح نہیں ہے کہ اس تازہ ترین وارننگ کو کہاں تلاش کرنا ہے۔
اس کہانی میں سب سے بری بات یہ ہے کہ اگر اس وقت اوپر سے کوئی آپ کو جامد کوڈ تجزیہ استعمال کرنے پر مجبور کرتا ہے۔ اس سے ٹیم کو صرف حوصلہ ملے گا، کیونکہ ان کے نقطہ نظر سے وہاں اضافی بیوروکریٹک پیچیدگی ہوگی جو صرف راستے میں آتی ہے۔ کوئی بھی تجزیہ کار کی رپورٹوں کو نہیں دیکھے گا، اور تمام استعمال صرف "کاغذ پر" ہوں گے۔ وہ. باضابطہ طور پر، تجزیے کو DevOps کے عمل میں شامل کیا جاتا ہے، لیکن عملی طور پر اس سے کسی کو فائدہ نہیں ہوتا ہے۔ ہم نے کانفرنس کے شرکاء سے بوتھ پر تفصیلی کہانیاں سنی۔ اس طرح کا تجربہ پروگرامرز کی حوصلہ شکنی کر سکتا ہے کہ وہ طویل عرصے تک جامد تجزیہ کے ٹولز استعمال کر سکیں، اگر ہمیشہ کے لیے نہیں۔
تکنیکی قرضوں کا نفاذ اور خاتمہ
درحقیقت، ایک بڑے پرانے منصوبے میں بھی جامد تجزیہ متعارف کرانے میں کوئی مشکل یا خوفناک بات نہیں ہے۔
CI / CD
مزید یہ کہ تجزیہ کار کو فوری طور پر مسلسل ترقی کے عمل کا حصہ بنایا جا سکتا ہے۔ مثال کے طور پر، PVS-Studio ڈسٹری بیوشن میں آپ کی ضرورت کے فارمیٹ میں رپورٹ کو آسانی سے دیکھنے کے لیے افادیتیں، اور کوڈ کے مسائل والے حصے لکھنے والے ڈویلپرز کے لیے اطلاعات شامل ہیں۔ ان لوگوں کے لیے جو CI/CD سسٹمز سے PVS-Studio شروع کرنے میں زیادہ دلچسپی رکھتے ہیں، میں تجویز کرتا ہوں کہ آپ اپنے آپ کو متعلقہ دستاویزات اور مضامین کا ایک سلسلہ:
لیکن آئیے کوڈ کے تجزیہ کے ٹولز کو لاگو کرنے کے پہلے مراحل میں غلط مثبتات کی ایک بڑی تعداد کے مسئلے پر واپس آتے ہیں۔
موجودہ تکنیکی قرضوں کو درست کرنا اور نئے انتباہات سے نمٹنا
جدید تجارتی جامد تجزیہ کار آپ کو صرف نئے انتباہات کا مطالعہ کرنے کی اجازت دیتے ہیں جو نئے یا تبدیل شدہ کوڈ میں ظاہر ہوتے ہیں۔ اس طریقہ کار کا نفاذ مختلف ہوتا ہے، لیکن جوہر ایک ہی ہے۔ PVS-Studio جامد تجزیہ کار میں، اس فعالیت کو مندرجہ ذیل طور پر لاگو کیا جاتا ہے۔
جامد تجزیہ کا استعمال تیزی سے شروع کرنے کے لیے، ہم تجویز کرتے ہیں کہ PVS-Studio صارفین انتباہات کو بڑے پیمانے پر دبانے کا طریقہ کار استعمال کریں [] عمومی خیال مندرجہ ذیل ہے۔ صارف نے تجزیہ کار لانچ کیا اور اسے بہت سے انتباہات موصول ہوئے۔ چونکہ ایک پروجیکٹ جو کئی سالوں سے ترقی میں ہے زندہ ہے، ترقی کر رہا ہے اور پیسہ کما رہا ہے، تو زیادہ تر امکان ہے کہ رپورٹ میں بہت سے انتباہات نہیں ہوں گے جو کہ اہم نقائص کی نشاندہی کرتے ہیں۔ دوسرے لفظوں میں، اہم کیڑے پہلے ہی زیادہ مہنگے طریقوں کا استعمال کرتے ہوئے یا صارفین کے تاثرات کی بدولت کسی نہ کسی طریقے سے ٹھیک کر دیے گئے ہیں۔ اس کے مطابق، تجزیہ کار کو فی الحال جو کچھ ملتا ہے اسے تکنیکی قرض سمجھا جا سکتا ہے، جسے فوری طور پر ختم کرنے کی کوشش کرنا ناقابل عمل ہے۔
آپ PVS-Studio سے کہہ سکتے ہیں کہ وہ ان انتباہات کو ابھی کے لیے غیر متعلقہ سمجھے (بعد میں تکنیکی قرض کو محفوظ کریں)، اور یہ انہیں مزید نہیں دکھائے گا۔ تجزیہ کار ایک خاص فائل بناتا ہے جہاں وہ ان غلطیوں کے بارے میں معلومات محفوظ کرتا ہے جو ابھی تک دلچسپ نہیں ہیں۔ اور اب PVS-Studio صرف نئے یا تبدیل شدہ کوڈ کے لیے وارننگ جاری کرے گا۔ مزید یہ کہ یہ سب ہوشیاری سے عمل میں لایا جاتا ہے۔ اگر، مثال کے طور پر، سورس کوڈ فائل کے آغاز میں ایک خالی لائن شامل کی جاتی ہے، تو تجزیہ کار سمجھتا ہے کہ، درحقیقت، کچھ بھی نہیں بدلا، اور وہ خاموش رہے گا۔ اس مارک اپ فائل کو ورژن کنٹرول سسٹم میں ڈالا جا سکتا ہے۔ فائل بڑی ہے، لیکن یہ کوئی مسئلہ نہیں ہے، کیونکہ اسے اکثر ذخیرہ کرنے کا کوئی فائدہ نہیں ہے۔
اب تمام پروگرامرز صرف نئے یا تبدیل شدہ کوڈ سے متعلق وارننگ دیکھیں گے۔ اس طرح، آپ تجزیہ کار کا استعمال شروع کر سکتے ہیں، جیسا کہ وہ کہتے ہیں، اگلے دن سے۔ اور آپ بعد میں تکنیکی قرض پر واپس جا سکتے ہیں، اور آہستہ آہستہ غلطیوں کو درست کر سکتے ہیں اور تجزیہ کار کو ترتیب دے سکتے ہیں۔
لہذا، ایک بڑے پرانے منصوبے میں تجزیہ کار کے نفاذ کے ساتھ پہلا مسئلہ حل ہو گیا ہے۔ اب آئیے دیکھتے ہیں کہ تکنیکی قرض کے ساتھ کیا کرنا ہے۔
بگ کی اصلاحات اور ری فیکٹرنگز
سب سے آسان اور فطری بات یہ ہے کہ بڑے پیمانے پر دبے ہوئے تجزیہ کار انتباہات کا تجزیہ کرنے کے لیے کچھ وقت نکالیں اور آہستہ آہستہ ان سے نمٹیں۔ کہیں آپ کو کوڈ میں غلطیوں کو دور کرنا چاہئے، کہیں آپ کو تجزیہ کار کو بتانے کے لئے ریفیکٹر کرنا چاہئے کہ کوڈ مسئلہ نہیں ہے۔ سادہ مثال:
if (a = b)زیادہ تر C++ مرتب کرنے والے اور تجزیہ کار ایسے کوڈ کے بارے میں شکایت کرتے ہیں، کیونکہ اس بات کا بہت زیادہ امکان ہے کہ وہ دراصل لکھنا چاہتے تھے۔ (a == b). لیکن ایک غیر بیان کردہ معاہدہ ہے، اور یہ عام طور پر دستاویزات میں نوٹ کیا جاتا ہے، کہ اگر اضافی قوسین ہیں، تو یہ سمجھا جاتا ہے کہ پروگرامر نے جان بوجھ کر ایسا کوڈ لکھا ہے، اور قسم کھانے کی ضرورت نہیں ہے۔ مثال کے طور پر، تشخیص کے لیے PVS-Studio دستاویزات میں واضح طور پر لکھا ہے کہ درج ذیل سطور درست اور محفوظ سمجھی جائیں گی۔
if ((a = b))ایک اور مثال. کیا یہ اس C++ کوڈ میں بھول گیا ہے؟ توڑ یا نہیں؟
case A:
foo();
case B:
bar();
break;PVS-Studio تجزیہ کار یہاں ایک انتباہ جاری کرے گا۔ . یہ ایک غلطی نہیں ہوسکتی ہے، ایسی صورت میں آپ کو انتساب کو شامل کرکے تجزیہ کار کو اشارہ دینا چاہئے یا مثال کے طور پر __خاصیت__((فال تھرو)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;یہ کہا جا سکتا ہے کہ کوڈ میں اس طرح کی تبدیلیاں بگ کو ٹھیک نہیں کرتی ہیں۔ جی ہاں، یہ سچ ہے، لیکن یہ دو مفید چیزیں کرتا ہے. سب سے پہلے، تجزیہ کار کی رپورٹ غلط مثبت سے چھٹکارا حاصل کرتی ہے. دوم، کوڈ اس کی دیکھ بھال میں شامل لوگوں کے لیے زیادہ قابل فہم ہو جاتا ہے۔ اور یہ بہت اہم ہے! صرف اس کے لیے، کوڈ کو واضح اور برقرار رکھنے میں آسان بنانے کے لیے معمولی ری فیکٹرنگ کرنا قابل قدر ہے۔ چونکہ تجزیہ کار یہ نہیں سمجھتا کہ آیا "بریک" کی ضرورت ہے یا نہیں، یہ ساتھی پروگرامرز کے لیے بھی واضح نہیں ہوگا۔
بگ فکسس اور ریفیکٹرنگز کے علاوہ، آپ واضح طور پر غلط تجزیہ کار انتباہات کو دبا سکتے ہیں۔ کچھ غیر متعلقہ تشخیص کو غیر فعال کیا جا سکتا ہے۔ مثال کے طور پر، کوئی سمجھتا ہے کہ انتباہات بے معنی ہیں۔ فلوٹ/ڈبل اقدار کا موازنہ کرنے کے بارے میں۔ اور کچھ ان کو اہم اور قابل مطالعہ قرار دیتے ہیں] کون سی تنبیہات متعلقہ سمجھی جاتی ہیں اور کون سی نہیں اس کا فیصلہ ترقیاتی ٹیم پر منحصر ہے۔
جھوٹے انتباہات کو دبانے کے اور بھی طریقے ہیں۔ مثال کے طور پر، میکرو مارک اپ کا ذکر پہلے کیا گیا تھا۔ یہ سب دستاویزات میں مزید تفصیل سے بیان کیا گیا ہے۔ سب سے اہم بات یہ سمجھنا ہے کہ اگر آپ بتدریج اور منظم طریقے سے جھوٹے مثبتات کے ساتھ کام کرتے ہیں تو ان میں کوئی حرج نہیں ہے۔ غیر دلچسپ انتباہات کی اکثریت کنفیگریشن کے بعد غائب ہو جاتی ہے، اور صرف وہ جگہیں جن کے لیے واقعی محتاط مطالعہ کی ضرورت ہوتی ہے اور کوڈ میں کچھ تبدیلیاں باقی رہتی ہیں۔
اس کے علاوہ، اگر کوئی مشکل پیش آتی ہے تو ہم PVS-Studio کے سیٹ اپ میں اپنے کلائنٹس کی ہمیشہ مدد کرتے ہیں۔ مزید یہ کہ، ایسے معاملات تھے جب ہم نے خود غلط انتباہات کو ختم کیا اور غلطیوں کو درست کیا [] صرف اس صورت میں، میں نے یہ بتانے کا فیصلہ کیا کہ توسیعی تعاون کے لیے یہ آپشن بھی ممکن ہے :)۔
شافٹ کا طریقہ
جامد تجزیہ کار انتباہ کو ختم کر کے کوڈ کے معیار کو بتدریج بہتر کرنے کا ایک اور دلچسپ طریقہ ہے۔ سب سے اہم بات یہ ہے کہ انتباہات کی تعداد صرف کم ہوسکتی ہے۔
جامد تجزیہ کار کے ذریعہ جاری کردہ انتباہات کی تعداد ریکارڈ کی جاتی ہے۔ کوالٹی گیٹ کو اس طرح ترتیب دیا گیا ہے کہ اب آپ صرف ایک کوڈ درج کر سکتے ہیں جو آپریشنز کی تعداد میں اضافہ نہیں کرتا ہے۔ نتیجے کے طور پر، تجزیہ کار کو ایڈجسٹ کرکے اور غلطیوں کو درست کرکے الارم کی تعداد کو بتدریج کم کرنے کا عمل شروع ہوتا ہے۔
یہاں تک کہ اگر کوئی شخص تھوڑا سا دھوکہ دینا چاہتا ہے اور اپنے نئے کوڈ میں وارننگز کو ختم کرکے نہیں بلکہ پرانے تھرڈ پارٹی کوڈ کو بہتر بنا کر کوالٹی گیٹ سے گزرنے کا فیصلہ کرتا ہے، تو یہ خوفناک نہیں ہے۔ سب کچھ ایک ہی ہے، شافٹ ایک سمت میں گھومتا ہے، اور آہستہ آہستہ خرابیوں کی تعداد کم ہوتی جائے گی. یہاں تک کہ اگر کوئی شخص اپنے نئے نقائص کو خود ٹھیک نہیں کرنا چاہتا ہے، تب بھی اسے پڑوسی کوڈ میں کچھ بہتر کرنا پڑے گا۔ کسی وقت، انتباہات کی تعداد کو کم کرنے کے آسان طریقے ختم ہو جاتے ہیں، اور ایک موقع آتا ہے جب حقیقی کیڑے ٹھیک ہو جاتے ہیں۔
یہ طریقہ کار Ivan Ponomarev کے ایک بہت ہی دلچسپ مضمون میں مزید تفصیل سے بیان کیا گیا ہے۔"، جسے میں کوڈ کے معیار کو بہتر بنانے میں دلچسپی رکھنے والے کسی کو پڑھنے کی تجویز کرتا ہوں۔
مضمون کے مصنف کی اس موضوع پر ایک رپورٹ بھی ہے: "".
حاصل يہ ہوا
مجھے امید ہے کہ اس مضمون کے بعد، قارئین جامد تجزیہ ٹولز کو زیادہ قبول کریں گے اور انہیں ترقی کے عمل میں لاگو کرنا چاہیں گے۔ اگر آپ کے کوئی سوالات ہیں تو ہم ہمیشہ تیار ہیں۔ ہمارے جامد تجزیہ کار PVS-Studio کے صارفین اور اس کے نفاذ میں مدد کرتے ہیں۔
اس بارے میں دوسرے عام شکوک و شبہات ہیں کہ آیا جامد تجزیہ واقعی آسان اور مفید ہو سکتا ہے۔ میں نے ان میں سے زیادہ تر شکوک و شبہات کو "ترقیاتی عمل میں PVS-Studio جامد کوڈ تجزیہ کار کو متعارف کرانے کی وجوہات" میں شائع کرنے کی کوشش کی۔].
آپ کی توجہ کا شکریہ اور آئیں اور PVS-Studio تجزیہ کار کو آزمائیں۔
اضافی لنکس۔
- آندرے کارپوف۔
- وکیپیڈیا. .
- آندرے کارپوف، وکٹوریہ خانیوا۔ .
- پی وی ایس اسٹوڈیو۔ دستاویزی. .
- آندرے کارپوف۔ .
- پی وی ایس اسٹوڈیو۔ دستاویزی. .
- ایوان اینڈریشین۔ .
- پاول ایریمیف، سویاتوسلاو رازمیسلوف۔ .
- آندرے کارپوف۔ .
اگر آپ انگریزی بولنے والے سامعین کے ساتھ اس مضمون کا اشتراک کرنا چاہتے ہیں، تو براہ کرم ترجمہ کا لنک استعمال کریں: Andrey Karpov۔ .
ماخذ: www.habr.com