جیسا کہ وہ کہتے ہیں، اگر آپ اپنے پرانے کوڈ پر شرمندہ نہیں ہیں، تو آپ ایک پروگرامر کے طور پر ترقی نہیں کر رہے ہیں - اور میں اس رائے سے متفق ہوں۔ میں نے 40 سال پہلے اور پیشہ ورانہ طور پر 30 سال پہلے تفریح کے لیے پروگرامنگ شروع کی تھی، اس لیے مجھ سے بہت سی غلطیاں ہیں۔ بہت. کمپیوٹر سائنس کے پروفیسر کے طور پر، میں اپنے طالب علموں کو غلطیوں سے سیکھنا سکھاتا ہوں — ان کی، میری اور دوسروں سے۔ مجھے لگتا ہے کہ اب وقت آگیا ہے کہ میں اپنی غلطیوں کے بارے میں بات کروں تاکہ میری شائستگی ضائع نہ ہو۔ مجھے امید ہے کہ وہ کسی کے لیے کارآمد ہوں گے۔
تیسرا مقام - مائیکروسافٹ سی کمپائلر
میرے اسکول کے استاد کا خیال تھا کہ رومیو اور جولیٹ کو ایک المیہ نہیں سمجھا جا سکتا کیونکہ کرداروں میں کوئی المناک جرم نہیں تھا - انہوں نے محض احمقانہ سلوک کیا، جیسا کہ نوعمروں کو کرنا چاہیے۔ میں تب اس سے اتفاق نہیں کرتا تھا، لیکن اب مجھے اس کی رائے میں معقولیت کا ایک دانہ نظر آتا ہے، خاص طور پر پروگرامنگ کے سلسلے میں۔
جب میں نے MIT میں اپنا سوفومور سال مکمل کیا، میں زندگی اور پروگرامنگ دونوں لحاظ سے جوان اور ناتجربہ کار تھا۔ موسم گرما میں، میں نے مائیکرو سافٹ میں سی کمپائلر ٹیم میں داخلہ لیا۔ پہلے تو میں نے روٹین کے کام کیے جیسے پروفائلنگ سپورٹ، اور پھر مجھے کمپائلر کے سب سے زیادہ پرلطف حصے (جیسا کہ میں نے سوچا) - بیک اینڈ آپٹیمائزیشن پر کام کرنے کی ذمہ داری سونپی گئی۔ خاص طور پر، مجھے برانچ اسٹیٹمنٹس کے لیے x86 کوڈ کو بہتر کرنا تھا۔
ہر ممکنہ معاملے کے لیے بہترین مشین کوڈ لکھنے کے لیے پرعزم، میں نے خود کو تالاب میں ڈال دیا۔ اگر اقدار کی تقسیم کی کثافت زیادہ تھی، تو میں نے ان میں داخل کیا۔ . اگر ان کے پاس ایک مشترکہ تقسیم ہے، تو میں نے اسے میز کو سخت بنانے کے لیے استعمال کیا (لیکن صرف اس صورت میں جب تقسیم کا استعمال کر کے کیا جا سکے۔ )۔ جب تمام اقدار دو کی طاقتیں تھیں، میں نے ایک اور اصلاح کی۔ اگر اقدار کے ایک سیٹ نے میری شرائط پوری نہیں کیں، تو میں نے اسے کئی قابل اصلاح صورتوں میں تقسیم کر دیا اور پہلے سے بہتر کردہ کوڈ کا استعمال کیا۔
یہ ایک ڈراؤنا خواب تھا۔ کئی سال بعد مجھے بتایا گیا کہ پروگرامر جس کو میرا کوڈ وراثت میں ملا وہ مجھ سے نفرت کرتا ہے۔
سبق سیکھا۔
جیسا کہ ڈیوڈ پیٹرسن اور جان ہینسی کمپیوٹر آرکیٹیکچر اور کمپیوٹر سسٹمز ڈیزائن میں لکھتے ہیں، فن تعمیر اور ڈیزائن کے بنیادی اصولوں میں سے ایک یہ ہے کہ عام طور پر چیزوں کو جلد سے جلد کام کرنا ہے۔
عام کیسز کو تیز کرنے سے نایاب کیسز کو بہتر بنانے سے زیادہ مؤثر طریقے سے کارکردگی میں بہتری آئے گی۔ ستم ظریفی یہ ہے کہ عام معاملات اکثر نایاب سے زیادہ آسان ہوتے ہیں۔ یہ منطقی مشورہ فرض کرتا ہے کہ آپ جانتے ہیں کہ کون سا معاملہ عام سمجھا جاتا ہے - اور یہ صرف محتاط جانچ اور پیمائش کے عمل سے ممکن ہے۔
اپنے دفاع میں، میں نے یہ جاننے کی کوشش کی کہ شاخ کے بیانات عملی طور پر کس طرح نظر آتے ہیں (جیسے کہ کتنی شاخیں تھیں اور کتنے مستقل تقسیم کیے گئے تھے)، لیکن 1988 میں یہ معلومات دستیاب نہیں تھیں۔ تاہم، جب بھی موجودہ مرتب کرنے والا مصنوعی مثال کے لیے زیادہ سے زیادہ کوڈ نہیں بنا سکتا تھا تو مجھے خصوصی کیسز شامل نہیں کرنا چاہیے تھے۔
مجھے ایک تجربہ کار ڈویلپر کو کال کرنے کی ضرورت تھی اور اس کے ساتھ مل کر اس بارے میں سوچیں کہ عام کیسز کیا ہیں اور خاص طور پر ان سے نمٹنا ہے۔ میں کم کوڈ لکھوں گا، لیکن یہ اچھی بات ہے۔ جیسا کہ اسٹیک اوور فلو کے بانی جیف اٹوڈ نے لکھا، ایک پروگرامر کا بدترین دشمن خود پروگرامر ہے:
میں جانتا ہوں کہ ہم سب کی طرح آپ کے بھی بہترین ارادے ہیں۔ ہم پروگرام بناتے ہیں اور کوڈ لکھنا پسند کرتے ہیں۔ اسی طرح ہم بنائے گئے ہیں۔ ہمارا خیال ہے کہ کسی بھی مسئلے کو ڈکٹ ٹیپ، گھر کی بنی ہوئی بیساکھی اور چٹکی بھر کوڈ سے حل کیا جا سکتا ہے۔ جتنا یہ کوڈرز کو تسلیم کرنے میں تکلیف دیتا ہے، بہترین کوڈ وہ کوڈ ہے جو موجود نہیں ہے۔ ہر نئی لائن کو ڈیبگنگ اور سپورٹ کی ضرورت ہوتی ہے، اسے سمجھنے کی ضرورت ہے۔ جب آپ نیا کوڈ شامل کرتے ہیں، تو آپ کو ہچکچاہٹ اور بیزاری کے ساتھ ایسا کرنا چاہیے کیونکہ دیگر تمام آپشنز ختم ہو چکے ہیں۔ بہت سے پروگرامر بہت زیادہ کوڈ لکھتے ہیں، جو اسے ہمارا دشمن بناتے ہیں۔
اگر میں نے آسان کوڈ لکھا ہوتا جس میں عام کیسز کا احاطہ کیا جاتا تو ضرورت پڑنے پر اسے اپ ڈیٹ کرنا بہت آسان ہوتا۔ میں نے اپنے پیچھے ایک گندگی چھوڑی جس سے کوئی بھی نمٹنا نہیں چاہتا تھا۔
دوسری جگہ: سوشل نیٹ ورکس پر اشتہار
جب میں گوگل پر سوشل میڈیا ایڈورٹائزنگ پر کام کر رہا تھا (مائی اسپیس یاد ہے؟)، میں نے C++ میں کچھ اس طرح لکھا:
for (int i = 0; i < user->interests->length(); i++) {
for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
keywords->add(user->interests(i)->keywords(i)) {
}
}پروگرامرز فوری طور پر غلطی دیکھ سکتے ہیں: آخری دلیل j ہونی چاہیے، i نہیں۔ یونٹ ٹیسٹنگ نے غلطی کو ظاہر نہیں کیا، اور نہ ہی میرے جائزہ لینے والے نے کیا۔ لانچ کیا گیا، اور ایک رات میرا کوڈ سرور پر چلا گیا اور ڈیٹا سینٹر میں موجود تمام کمپیوٹرز کو کریش کر دیا۔
کچھ برا نہیں ہوا۔ کسی کے لیے کچھ نہیں ٹوٹا، کیونکہ عالمی لانچ سے پہلے کوڈ کا تجربہ ایک ڈیٹا سینٹر میں کیا جاتا تھا۔ جب تک کہ SRE انجینئرز نے کچھ دیر کے لیے بلیئرڈ کھیلنا بند کر دیا اور تھوڑا سا رول بیک کیا۔ اگلی صبح مجھے کریش ڈمپ کے ساتھ ایک ای میل موصول ہوا، کوڈ کو درست کیا اور یونٹ ٹیسٹ شامل کیے جو غلطی کو ظاہر کر دیں گے۔ چونکہ میں نے پروٹوکول کی پیروی کی ہے - بصورت دیگر میرا کوڈ چلنے میں ناکام ہوجائے گا - اس کے علاوہ کوئی اور مسئلہ نہیں تھا۔
سبق سیکھا۔
بہت سے لوگوں کو یقین ہے کہ اس طرح کی ایک بڑی غلطی یقینی طور پر مجرم کو برخاست کرنے کی قیمت ادا کرے گی، لیکن ایسا نہیں ہے: سب سے پہلے، تمام پروگرامرز غلطیاں کرتے ہیں، اور دوسری بات، وہ شاذ و نادر ہی ایک ہی غلطی دو بار کرتے ہیں۔
درحقیقت، میرا ایک پروگرامر دوست ہے جو ایک شاندار انجینئر تھا اور اسے ایک غلطی کرنے پر نکال دیا گیا تھا۔ اس کے بعد، اسے گوگل پر رکھا گیا (اور جلد ہی ترقی دی گئی) - اس نے ایک انٹرویو میں اپنی غلطی کے بارے میں ایمانداری سے بات کی، اور اسے مہلک نہیں سمجھا گیا۔
یہ کیا ہے؟ IBM کے افسانوی سربراہ تھامس واٹسن کے بارے میں:
تقریباً ایک ملین ڈالر مالیت کے سرکاری آرڈر کا اعلان کیا گیا۔ IBM کارپوریشن - یا اس کے بجائے، تھامس واٹسن سینئر ذاتی طور پر - واقعی اسے حاصل کرنا چاہتے تھے۔ بدقسمتی سے، سیلز کا نمائندہ ایسا کرنے سے قاصر تھا اور IBM بولی ہار گیا۔ اگلے دن، یہ ملازم مسٹر واٹسن کے دفتر میں آیا اور اس کی میز پر ایک لفافہ رکھ دیا۔ مسٹر واٹسن نے اسے دیکھنے کی زحمت تک نہیں کی - وہ ایک ملازم کا انتظار کر رہے تھے اور جانتے تھے کہ یہ استعفیٰ کا خط تھا۔
واٹسن نے پوچھا کہ کیا ہوا؟
سیلز کے نمائندے نے ٹینڈر کی پیشرفت کے بارے میں تفصیل سے بات کی۔ اس نے ان غلطیوں کا نام لیا جن سے بچا جا سکتا تھا۔ آخر میں، اس نے کہا، "مسٹر واٹسن، مجھے وضاحت کرنے کے لیے آپ کا شکریہ۔ میں جانتا ہوں کہ ہمیں اس آرڈر کی کتنی ضرورت ہے۔ میں جانتا ہوں کہ وہ کتنا اہم تھا،" اور جانے کے لیے تیار ہو گیا۔
واٹسن دروازے پر اس کے قریب پہنچا، اس کی آنکھوں میں دیکھا اور لفافہ واپس کرتے ہوئے کہا: "میں تمہیں کیسے جانے دوں؟ میں نے ابھی آپ کی تعلیم میں ایک ملین ڈالر کی سرمایہ کاری کی ہے۔
میرے پاس ایک ٹی شرٹ ہے جس میں لکھا ہے: "اگر آپ واقعی غلطیوں سے سیکھتے ہیں، تو میں پہلے سے ہی ماسٹر ہوں۔" درحقیقت، جب غلطیوں کی بات آتی ہے، تو میں سائنس کا ڈاکٹر ہوں۔
پہلی جگہ: App Inventor API
واقعی خوفناک غلطیاں صارفین کی ایک بڑی تعداد کو متاثر کرتی ہیں، عوام کے علم میں آ جاتی ہیں، درست کرنے میں کافی وقت لگتا ہے، اور ان لوگوں کی طرف سے کی جاتی ہیں جو انہیں نہیں بنا سکتے تھے۔ میری سب سے بڑی غلطی ان تمام معیارات پر فٹ بیٹھتی ہے۔
جتنا برا اتنا ہی اچھا
میں پڑھتا ہوں ایک گریجویٹ طالب علم کے طور پر نوے کی دہائی میں اس نقطہ نظر کے بارے میں، اور مجھے یہ اتنا پسند ہے کہ میں اسے اپنے طلباء سے پوچھتا ہوں۔ اگر آپ کو اچھی طرح یاد نہیں ہے تو اپنی یادداشت کو تازہ کریں، یہ چھوٹی ہے۔ یہ مضمون سادگی سمیت کئی طریقوں سے "اسے درست کرنے" اور "بدتر بہتر ہے" کی خواہش سے متصادم ہے۔
یہ کیسا ہونا چاہئے: ڈیزائن کو لاگو کرنے اور انٹرفیس میں آسان ہونا چاہئے۔ انٹرفیس کی سادگی عمل درآمد کی سادگی سے زیادہ اہم ہے۔
بدتر، بہتر: ڈیزائن کو لاگو کرنے اور انٹرفیس میں آسان ہونا چاہئے. عمل درآمد کی سادگی انٹرفیس کی سادگی سے زیادہ اہم ہے۔
آئیے ایک منٹ کے لیے اس کے بارے میں بھول جائیں۔ بدقسمتی سے، میں کئی سالوں کے لئے اس کے بارے میں بھول گیا.
ایپ موجد
گوگل میں کام کرنے کے دوران، میں ٹیم کا حصہ تھا۔ ، خواہش مند Android ڈویلپرز کے لیے ایک ڈریگ اینڈ ڈراپ آن لائن ترقی کا ماحول۔ یہ 2009 تھا، اور ہم وقت پر الفا ورژن جاری کرنے کی جلدی میں تھے تاکہ گرمیوں میں ہم اساتذہ کے لیے ماسٹر کلاسز کا انعقاد کر سکیں جو موسم خزاں میں پڑھاتے وقت ماحول کو استعمال کر سکیں۔ میں نے TI-99/4 پر گیمز لکھنے کے لیے پرانی یادوں سے، اسپرائٹس کو نافذ کرنے کے لیے رضاکارانہ طور پر کام کیا۔ ان لوگوں کے لیے جو نہیں جانتے، سپرائٹ ایک دو جہتی گرافیکل آبجیکٹ ہے جو دوسرے سافٹ ویئر عناصر کے ساتھ حرکت اور تعامل کر سکتا ہے۔ اسپرائٹس کی مثالوں میں خلائی جہاز، کشودرگرہ، ماربلز اور ریکٹس شامل ہیں۔
ہم نے جاوا میں آبجیکٹ اورینٹڈ ایپ انوینٹر کو لاگو کیا، لہذا وہاں پر اشیاء کا ایک گروپ ہے۔ چونکہ گیندیں اور اسپرائٹس بہت یکساں برتاؤ کرتے ہیں، اس لیے میں نے پراپرٹیز (فیلڈز) X، Y، Speed (رفتار) اور Heading (direction) کے ساتھ ایک خلاصہ اسپرائٹ کلاس بنائی۔ ان کے پاس تصادم کا پتہ لگانے، اسکرین کے کنارے کو اچھالنے وغیرہ کے ایک جیسے طریقے تھے۔
گیند اور سپرائٹ کے درمیان بنیادی فرق وہی ہے جو بالکل کھینچا جاتا ہے - ایک بھرا ہوا دائرہ یا ایک راسٹر۔ چونکہ میں نے پہلے اسپرائٹس کو لاگو کیا تھا، اس لیے جہاں تصویر واقع تھی اس کے اوپری بائیں کونے کے x- اور y- کوآرڈینیٹس کی وضاحت کرنا منطقی تھا۔
ایک بار جب اسپرائٹس کام کر رہے تھے، میں نے فیصلہ کیا کہ میں بہت کم کوڈ کے ساتھ بال اشیاء کو لاگو کر سکتا ہوں۔ صرف ایک مسئلہ یہ تھا کہ میں نے سب سے آسان راستہ اختیار کیا (عمل درآمد کرنے والے کے نقطہ نظر سے)، جو گیند کو تیار کرنے والے سموچ کے اوپری بائیں کونے کے x- اور y- نقاط کی نشاندہی کرتا ہے۔
درحقیقت، دائرے کے مرکز کے x- اور y- نقاط کی نشاندہی کرنا ضروری تھا، جیسا کہ ریاضی کی کسی بھی نصابی کتاب میں پڑھایا جاتا ہے اور کسی دوسرے ماخذ میں جو حلقوں کا ذکر کرتا ہے۔
میری ماضی کی غلطیوں کے برعکس، اس نے نہ صرف میرے ساتھیوں کو بلکہ لاکھوں ایپ انوینٹر صارفین کو بھی متاثر کیا۔ ان میں سے بہت سے بچے تھے یا پروگرامنگ میں بالکل نئے تھے۔ ہر اس ایپلی کیشن پر کام کرتے ہوئے جس میں گیند موجود تھی انہیں بہت سارے غیر ضروری اقدامات کرنے پڑتے تھے۔ اگر میں اپنی دوسری غلطیوں کو ہنسی کے ساتھ یاد کرتا ہوں تو یہ غلطی آج بھی مجھے پسینہ آجاتی ہے۔
میں نے آخر کار اس مسئلے کو ابھی حال ہی میں، دس سال بعد ٹھیک کیا۔ "پیچڈ"، "فکسڈ" نہیں، کیونکہ جیسا کہ جوشوا بلوچ کہتے ہیں، APIs ابدی ہیں۔ موجودہ پروگراموں پر اثر انداز ہونے والی تبدیلیاں کرنے سے قاصر، ہم نے OriginAtCenter پراپرٹی کو پرانے پروگراموں میں غلط اور مستقبل کے تمام پروگراموں میں درست کے ساتھ شامل کیا۔ صارف ایک منطقی سوال پوچھ سکتے ہیں: جس نے نقطہ آغاز کو مرکز کے علاوہ کہیں اور رکھنے کا سوچا بھی۔ کس سے؟ ایک پروگرامر کو جو دس سال پہلے ایک عام API بنانے میں بہت سست تھا۔
سبق سیکھا
APIs پر کام کرتے وقت (جو تقریباً ہر پروگرامر کو بعض اوقات کرنا پڑتا ہے)، آپ کو جوشوا بلوچ کی ویڈیو میں بیان کردہ بہترین مشورے پر عمل کرنا چاہیے۔"یا :
- ایک API آپ کو بڑا فائدہ اور بڑا نقصان پہنچا سکتا ہے۔. ایک اچھا API دوبارہ گاہکوں کو تخلیق کرتا ہے. برا آپ کا ابدی خواب بن جاتا ہے۔
- عوامی APIs، ہیروں کی طرح، ہمیشہ کے لیے قائم رہتے ہیں۔. اسے اپنا سب کچھ دیں: سب کچھ ٹھیک کرنے کا دوسرا موقع کبھی نہیں ملے گا۔
- API کا خاکہ مختصر ہونا چاہیے۔ - کلاس اور طریقہ کار کے دستخطوں اور وضاحتوں کے ساتھ ایک صفحہ، ایک لائن سے زیادہ نہیں لے رہا ہے۔ یہ آپ کو آسانی سے API کی تنظیم نو کرنے کی اجازت دے گا اگر یہ پہلی بار کامل نہیں ہوتا ہے۔
- استعمال کے معاملات کی وضاحت کریں۔API کو لاگو کرنے یا اس کی تفصیلات پر کام کرنے سے پہلے۔ اس طرح آپ مکمل طور پر غیر فعال API کو نافذ کرنے اور اس کی وضاحت کرنے سے گریز کریں گے۔
اگر میں مصنوعی رسم الخط کے ساتھ ایک مختصر سا خلاصہ بھی لکھ دیتا تو غالباً میں غلطی کی نشاندہی کر کے اسے درست کر دیتا۔ اگر نہیں، تو میرا ایک ساتھی ضرور کرتا۔ کوئی بھی فیصلہ جس کے دور رس نتائج ہوں اس کے بارے میں کم از کم ایک دن سوچنے کی ضرورت ہے (اس کا اطلاق نہ صرف پروگرامنگ پر ہوتا ہے)۔
رچرڈ گیبریل کے مضمون کا عنوان، "بدتر ہے بہتر،" اس فائدے کی طرف اشارہ کرتا ہے جو مارکیٹ میں سب سے پہلے ہونے کی طرف جاتا ہے — یہاں تک کہ ایک نامکمل پروڈکٹ کے ساتھ بھی — جب کہ کوئی اور کامل کا پیچھا کرنے میں ہمیشہ کی زندگی گزارتا ہے۔ اسپرائٹ کوڈ پر غور کرتے ہوئے، میں سمجھتا ہوں کہ مجھے اسے درست کرنے کے لیے مزید کوڈ لکھنے کی ضرورت نہیں تھی۔ کوئی جو بھی کہے، مجھ سے بڑی غلطی ہوئی۔
حاصل يہ ہوا
پروگرامرز ہر روز غلطیاں کرتے ہیں، چاہے وہ بگی کوڈ لکھنا ہو یا کوئی ایسی چیز آزمانا نہیں چاہتے جو ان کی مہارت اور پیداواری صلاحیت کو بہتر بنائے۔ یقینا، آپ اتنی سنگین غلطیاں کیے بغیر پروگرامر بن سکتے ہیں جیسا کہ میں نے کیا تھا۔ لیکن اپنی غلطیوں کو پہچانے اور ان سے سیکھے بغیر اچھا پروگرامر بننا ناممکن ہے۔
میں مسلسل ایسے طالب علموں کا سامنا کرتا ہوں جو محسوس کرتے ہیں کہ وہ بہت زیادہ غلطیاں کرتے ہیں اور اس وجہ سے پروگرامنگ کے لیے نہیں کٹے جاتے۔ میں جانتا ہوں کہ IT میں امپوسٹر سنڈروم کتنا عام ہے۔ مجھے امید ہے کہ آپ وہ سبق سیکھیں گے جو میں نے درج کیے ہیں - لیکن اہم کو یاد رکھیں: ہم میں سے ہر ایک غلطیاں کرتا ہے - شرمناک، مضحکہ خیز، خوفناک۔ میں حیران اور پریشان ہوں گا اگر مستقبل میں میرے پاس مضمون کو جاری رکھنے کے لیے کافی مواد نہیں ہے۔
ماخذ: www.habr.com